My Library _passes_ TaskSpeed in IE < 7

S

Scott Sauyet

Usinging such a static API can keep code from blowing up but it can
also obscure API misuse and cause other problems.

It can, and it's also more flexible. But it is less convenient, and
that really is a consideration.

For instance, this is certainly fine for me:

API.roundCorners(myDiv);

And this is overkill:

if (API.roundCorners) {
API.roundCorners(myDiv);
}

Because rounded corners are merely a nice touch, and not something I
care to make a big deal about in my code.

And while there are times I might appreciate this flexibility:

if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none';
}

It's also pretty nice to be able to do this:

API.myCoolFade(myDiv)

and know that the library is internally checking API.canSetOpacity and
whatever other flags it needs, then defaulting to its own
"style.display = 'none'" branch if the effects are not available.

I know that such a technique is less flexible. For instance, I
couldn't choose to do this:

if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
var warning = document.createElement("H3");
myDiv.insertBefore(warning, myDiv.firstChild);
for (var i = 0; i < 5; i++) {
setTimeout((function(seconds) {
return function() {
warning.innerHTML = "This div will " +
"self-destruct in " + seconds +
" seconds!";
};
})(5 - i), 1000 * i);
}
setTimeout(function() {
myDiv.style.display = 'none';
}, 5000);
}

but I'm often willing to sacrifice such flexibility for the simplicity
of the static API.
[ ... ]
A library could provide a static API and provide a separate mechanism
for determining browser support of each function, but I don't know
that that would be advantageous in any way aside from allowing lazily-
written, terser code.

Of course that last phrase can also be written "simpler, clearer
code". :)

One technique I've used on several occasions in my own mini-library
code is to add "supported" properties to API functions, which return
values "complete", "degrade", "empty", or false, depending upon
whether the function is completely supported, degrades acceptably,
returns empty objects or arrays, or is totally unsupported, with code
something like this:

API.myCoolFade = API._support((function() {
if (API.opacitySupported) return "complete";
return "degrade";
)(), function(elt) {
if (API.opacitySupported) {
// cool opacity animation here.
} else {
if (elt) elt.style.display = 'none';
}
});

The _support function simply adds the 'supported' property to the
function supplied as the second parameter, with the value supplied in
the first parameter, and returns this enhanced function.

It can then be used simply, if I don't care:

API.roundCorner(myDiv);

Or I can test if I like:

if (API.myCoolFade.supported) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none'
}

Or if I really want my own alternate degrading technique, I can check
the value of supported:

if (API.myCoolFade.supported == "complete") {
API.myCoolFade(myDiv);
} else if (API.myCoolFade.supported == "degrade") {
// My hand-rolled alternate hide technique here.
} else {
myDiv.style.display = 'none'
}

It has worked for me, but I haven't had to use it much, because it's
never been for large public APIs. It was exactly this sort of pseudo-
fade that motivated it, though, and it worked well enough there. For
API methods that returned arrays of nodes, usually there is complete
support across browsers, but when there isn't, the "supported"
property tells me that the function will at least return me an array I
could continue to process, even if it's empty, which often simplified
further coding.

In any case, I've never tried to code in the dynamic API style for
library code. Are there good examples of libraries that do it? I
understand My Library does; are there other publicly available
examples?

-- Scott
 
D

David Mark

Scott said:
It can, and it's also more flexible. But it is less convenient, and
that really is a consideration.

For instance, this is certainly fine for me:

API.roundCorners(myDiv);

And this is overkill:

if (API.roundCorners) {
API.roundCorners(myDiv);
}

No, you do _not_ do it that way. You do a one-time check at the start
for required methods.
Because rounded corners are merely a nice touch, and not something I
care to make a big deal about in my code.

And while there are times I might appreciate this flexibility:

if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none';
}

It's also pretty nice to be able to do this:

API.myCoolFade(myDiv)

Not at all nice when it blows up or fails silently. ;)
and know that the library is internally checking API.canSetOpacity and
whatever other flags it needs, then defaulting to its own
"style.display = 'none'" branch if the effects are not available.

Too much bloat and inefficiency in the internal code.
I know that such a technique is less flexible. For instance, I
couldn't choose to do this:

if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
var warning = document.createElement("H3");
myDiv.insertBefore(warning, myDiv.firstChild);
for (var i = 0; i < 5; i++) {
setTimeout((function(seconds) {
return function() {
warning.innerHTML = "This div will " +
"self-destruct in " + seconds +
" seconds!";
};
})(5 - i), 1000 * i);
}
setTimeout(function() {
myDiv.style.display = 'none';
}, 5000);
}

but I'm often willing to sacrifice such flexibility for the simplicity
of the static API.

But a static API can't abstract a an unknown environment in any sort of
efficient and flexible manner.
[ ... ]
A library could provide a static API and provide a separate mechanism
for determining browser support of each function, but I don't know
that that would be advantageous in any way aside from allowing lazily-
written, terser code.

Of course that last phrase can also be written "simpler, clearer
code". :)

One technique I've used on several occasions in my own mini-library
code is to add "supported" properties to API functions, which return
values "complete", "degrade", "empty", or false, depending upon
whether the function is completely supported, degrades acceptably,
returns empty objects or arrays, or is totally unsupported, with code
something like this:

Okay, but I don't see why you would need more than a boolean (e.g. works
or not).
API.myCoolFade = API._support((function() {
if (API.opacitySupported) return "complete";
return "degrade";
)(), function(elt) {
if (API.opacitySupported) {
// cool opacity animation here.
} else {
if (elt) elt.style.display = 'none';
}
});

See what I mean about bloat? Imagine an API with thousands of methods
doing something like this for each one. It wouldn't be feasible on the Web.
The _support function simply adds the 'supported' property to the
function supplied as the second parameter, with the value supplied in
the first parameter, and returns this enhanced function.

It can then be used simply, if I don't care:

API.roundCorner(myDiv);

Or I can test if I like:

if (API.myCoolFade.supported) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none'
}

Or if I really want my own alternate degrading technique, I can check
the value of supported:

if (API.myCoolFade.supported == "complete") {
API.myCoolFade(myDiv);
} else if (API.myCoolFade.supported == "degrade") {
// My hand-rolled alternate hide technique here.
} else {
myDiv.style.display = 'none'
}

But this is not efficient. A one-off gateway at the start is all you
need. Checking these things each time will bog down your app.
It has worked for me, but I haven't had to use it much, because it's
never been for large public APIs. It was exactly this sort of pseudo-
fade that motivated it, though, and it worked well enough there. For
API methods that returned arrays of nodes, usually there is complete
support across browsers, but when there isn't, the "supported"
property tells me that the function will at least return me an array I
could continue to process, even if it's empty, which often simplified
further coding.

Yes, for a small Intranet app, you could certainly get by with the above
(depending on its performance requirements of course).
In any case, I've never tried to code in the dynamic API style for
library code. Are there good examples of libraries that do it? I
understand My Library does; are there other publicly available
examples?

Not that I know of. :)
 
G

Garrett Smith

Peter said:
Peter Michaux wrote:
[...]

Some web applications benefit greatly from drag-and-drop
functionality. They benefit so greatly and the non-drag-and-drop
version is so bad that the non-drag-and-drop version is never built.
There are some some web applications that you could say *require*
drag-and-drop: games, drawing programs. There is no financial
incentive to building the non-drag-and-drop version. Drag-and-drop in
a web page doesn't seem to work on my iPhone. So it isn't that the
decision makers of the web page were "The Crazies". It is actually the
phone and/or the phone's browser that is not up to the task.
Drag'n'drop in iPhone requires a lot of extra effort. Yes the makers of
the iPhone were not up to much tasks other than marketing.

Try changing an iPhone's battery, for example.
 
P

Peter Michaux

Drag'n'drop in iPhone requires a lot of extra effort.

How would drag and drop even work in iPhone's Safari browser? It seems
that gestures are already so heavily used there aren't many gestures
available for drag and drop functionality.

Yes the makers of
the iPhone were not up to much tasks other than marketing.

That statement doesn't mean much.

Try changing an iPhone's battery, for example.

I can see Apple's argument that a user-changable battery requires more
casing/size and so is not desirable. I should, however, be able to
stop at a local Apple store and have the battery changed in a couple
minutes.

Peter
 
D

David Mark

Peter said:
How would drag and drop even work in iPhone's Safari browser? It seems
that gestures are already so heavily used there aren't many gestures
available for drag and drop functionality.

Ham-fisted. If you can't detect mousemove, bail on DnD. Simple as
that. Trying to bastardize gestures to to DnD is er Crazy. :)
 
G

Garrett Smith

Peter said:
How would drag and drop even work in iPhone's Safari browser? It seems
that gestures are already so heavily used there aren't many gestures
available for drag and drop functionality.

Touch-move-scrolls-the-viewport interferes touch move actions being
mapped to mousemove. So how do you make drag'n'drop work on iPhone?

To address this situation, Apple created a Touch Events API.

To use the Touch Events API for your typical drag'n'drop application,
register touch events "touchstart", "touchmove", and "touchend".

The the data need for the drag and drop event (pageX, etc) is not on the
event arg. Instead, it is found on from a Touch object on a TouchList
object. The TouchList object is found by eventArg.touches and the Touch
object is eventArg.touches.

In the touchmove event handler, call preventDefault to stop the browser
from scrolling the document around.

To unit test, Apple created the 18 parameter variable method
createTouchEvent.

Three of the 18 parameter variables to createTouchEvent are TouchList
objects. A TouchList object is created using document.createTouchList
and requires at least one Touch object.

A Touch object is created using document.createTouch.

I dislike the existence of proprietary APIs. This particular API is
significantly painful to use and test, so even if it were a standard
proposal, it has significant problems. The 18 parameter variables are
nearly impossible to remember and are irrelevant for most applications.

You'll also notice that scrolling works differently on iPhone. CSS
overflow auto and scroll values do not work.

I hold copyright to my counterproposal, which has been published on this
NG.

Most of the time the program can just allow single touch drag/drop, and
anything else might be just discarded. The "anything else" would be
user's palm touching the screen, or an attempt to do multi-finger drags.

If you'd like to see an example of some code, I can post a link.
That statement doesn't mean much.

I guess I used the wrong word "maker" there.

The people who are actually *making* the iPhone (Chinese workers)
probably could not use there entire year salary to purchase one.
I can see Apple's argument that a user-changable battery requires more
casing/size and so is not desirable. I should, however, be able to
stop at a local Apple store and have the battery changed in a couple
minutes.
Is that what Apple argued? I've got to see that. Where is it?
 
G

Garrett Smith

Garrett said:
[...]
The people who are actually *making* the iPhone (Chinese workers)
probably could not use there entire year salary to purchase one.
s/there/their
 
P

Peter Michaux

Is that what Apple argued? I've got to see that. Where is it?

I don't have a link but when the non-changable battery was first used
in the MacBook Pro the argument was that by saving the casing on the
battery and the housing where the battery mounts, they could instead
make the battery bigger for the same/similar weight and size.

Peter
 
D

David Mark

Jorge said:
Jeez, what a douchebag.

LOL. Internet tough-guy, huh? Not to mention freeloader. Perhaps you
think intellectual property is an antiquated notion? I know that other
have-nots share that view and it is obvious why that is the case. You
just can't have everything handed to you for free, Internet or no Internet.

Get better Jorge!
 
G

Garrett Smith

David said:
LOL. Internet tough-guy, huh? Not to mention freeloader. Perhaps you
think intellectual property is an antiquated notion? I know that other
have-nots share that view and it is obvious why that is the case. You
just can't have everything handed to you for free, Internet or no Internet.

Get better Jorge!
I would have shared the idea with the w3c, but they don't want it. On
the topic of "Touch and Gesture Events" Kari Hitola posted some wrong
information. He made statements that were false or incorrect. The
statements that were /provably/ false I provided one test case and a
link (to correct information). For other statements, IIRC, I questioned
him, but then got a notice that my "posting privilege had been suspended
for two weeks." All of my posts have been blocked since then. I have
tried to post even this month, IIRC. I can post to neither
public-script-coord, nor www-dom, nor public-webapps. I can still post
to www-style. I can't figure the rationale for picking those three
lists, so I can only assume it was blind anger and stupidity and they
overlooked www-style.

I stand by what I wrote and do not apologize for it. To the best of my
ability, I will continue question what I believe to be a misguided API
design.

The reason for Kari Hitola's posting, AISI, was to justify Nokia's copy
of Apple's API, post hoc.

If the w3c wants to block out my ideas from their lists, that's their
loss. I believe my idea is good and simple.

Those same W3C individuals might like the idea if they wrote it
themselves. They may do just that, but the idea is so simple that they
will probably expand on it and make it larger and more complicated.
 
D

David Mark

Garrett said:
I would have shared the idea with the w3c, but they don't want it. On
the topic of "Touch and Gesture Events" Kari Hitola posted some wrong
information. He made statements that were false or incorrect. The
statements that were /provably/ false I provided one test case and a
link (to correct information). For other statements, IIRC, I questioned
him, but then got a notice that my "posting privilege had been suspended
for two weeks." All of my posts have been blocked since then. I have
tried to post even this month, IIRC. I can post to neither
public-script-coord, nor www-dom, nor public-webapps. I can still post
to www-style. I can't figure the rationale for picking those three
lists, so I can only assume it was blind anger and stupidity and they
overlooked www-style.

Yes, I *hate* officious moderators. Near as I can tell, as soon as more
than one person cries for a ban, they do it. It's idiotic behavior as
they are really supposed to be manual Spam filters (and nothing more).
I can only imagine what these weenies are like in real life.

Dojo just installed a moderator on their new jQuery-powered forum,
apparently because they felt I was tarnishing their "sterling" legacy by
pointing out gaping holes in their foundation (that I had pointed out
months earlier, apparently to no avail or even understanding). Granted,
one idiot kept posting the same bad joke after each one like some sort
of bot, but I don't think that's what triggered the moderation. Now
there are some losers for you. Can't rebut anything logically, don't
understand how to fix anything (and therefore are constantly fucking up
royally), so they cry for bans and/or moderation (happened on their last
mailing list too) rather trying to understand what all (or any) of the
criticism is actually about.

And the most ironic, inexplicable bit is that I was originally _asked_
to pound some sense into them (and their code) by the project _owners_.
It's really beyond bizarre. At one point, one of those owners started
chiming in with some of the bitchiest, most ignorant bullshit I have
ever heard (and as you can imagine, that's up against some pretty stiff
competition).

I suppose there is a book chapter in it, but nobody would believe such a
far-fetched scenario and, at this point, I don't think there's enough
interest in that project to justify it anyway. I think they've finally
burned their last bridge to competence (and the relevance that could
come with it), because I have absolutely had it with them. I keep
trying to lead them to water and they keep opting for the spiked
Kool-aid instead (and shrieking up a storm in the process). :(

For instance, the one-liner "global" eval method is obviously broken and
no matter how many times I tell them how to fix it, it remains as is. I
suspect it is because nobody in the project is confident enough to
change anything in the core (in their mind it "just works", so the best
bet is to leave it alone). Then there are the synchronous Ajax
requests, the miles of browser sniffs, CSS parse hacks, and the classic
"overloading", even using typeof xyz == 'array' (though I think they did
_finally_ change that last one). And as there are about a thousand
files involved (quantity over quality of course), the snail's pace of
the epiphanies dawning is fatal to the effort. Like I have time to
repeat the same points to them a hundred times (getting splitting
headaches from the shrill bleating that seems to accompany each for my
trouble). There's too much to fix, too little time and too many
neophytes trying to prop themselves up as experts to make any real headway.
I stand by what I wrote and do not apologize for it. To the best of my
ability, I will continue question what I believe to be a misguided API
design.

The reason for Kari Hitola's posting, AISI, was to justify Nokia's copy
of Apple's API, post hoc.

If the w3c wants to block out my ideas from their lists, that's their
loss. I believe my idea is good and simple.

Those same W3C individuals might like the idea if they wrote it
themselves.

Yes, that keeps happening with the Dojo contributors too. I handed them
most of the answers on a silver platter, but they are full of excuses as
to why they would rather stick with what they have (or, as in the case
of the loader, they run off to write their own botched imitation). I
suppose I could understand if they were experiencing some modicum of
success, but I keep seeing complaints about the same old issues (often
things I fixed in my branch last summer). And just who is using their
stuff on the Web anyway? It's like they are developing with blinders
on. They want to shield themselves from criticism so they can "get back
to having fun again." What a fucking waste. :(

Also, I just noticed, their moderation mechanism must be broken as I
keep getting messages that my last post is "pending", yet it is clearly
there for all to see. Good thing too as it has some very useful
information in it (and isn't critical of Dojo specifically). But I've
informed the higher-ups that it will be my last post there as I won't
submit input to have it sit around waiting for some beetle-browed nitwit
to dismiss as "not fun." I mean, who are they to judge the merits of
points that they clearly don't understand?

As an aside, the aforementioned jQuery-ified forum loads _forever_ in
Opera 10, with the stop/reload button flashing like a strobe light
(epileptic or easily annoyed Opera users should steer clear). FF
politely says it is loading forever in the status bar. And I see random
server side exception vomiting from time to time as well. They can't
seem to do _anything_ right, but somehow they see it all as par for the
course, just gettin' stuff done, etc. and anyone who points out their
follies is a jerk for embarrassing them. I guess if you are never
successful, you can't recognize even the most obvious signs of failure. :(
 
D

David Mark

Peter said:
That's not a misprint. The documentation pages have jQuery 1.2x as
well. Yeah, I know. Their Web developers just like gettin' stuff done,
even when it is obviously destroying whatever shred of credibility they
have left. I can't explain it. I'm tired of thinking about as it gives
me headaches. :(
 
S

Scott Sauyet

David said:
No, you do _not_ do it that way.  You do a one-time check at the start
for required methods.

Do you centralize all code that might need rounded corners, then? If
so, how do you deal with dynamic changes to the DOM? Or do you store
a variable with the result of API,roundCorners? If it's that, how
much savings do you really get?

Not at all nice when it blows up or fails silently.  ;)

Of course, but my whole post was about ways to make a static API
available that doesn't blow up or fail silently even in the absence of
features we would like.

Too much bloat and inefficiency in the internal code.

Unless I actually can note performance issues, I'm much more concerned
with clean APIs that are as easy to use as possible than I am about
bloat in the library code.

But if performance is a concern, this can be done efficiently. It can
still be an up-front check:

API.myCoolFade = (API.opacitySupported)
? function(elt) {
// cool opacity animation here.
}
: function(elt) {
if (elt) elt.style.display = 'none';
}

But a static API can't abstract a an unknown environment in any sort of
efficient and flexible manner.

I certainly agree that a dynamic API can be more flexible; that's
practically tautological. I'm not sure I agree about the efficiency
question. To me the main question is whether the behavior of the
static API can degrade in a reasonable manner in environment that
don't support its full functionality.

Okay, but I don't see why you would need more than a boolean (e.g. works
or not).

I've done that.too. It works fine. The trouble is then if there is a
simpler supported version of the functionality with fewer bells and
whistles that I can fall back on. It's nice to have the super-cool
fade fall back on a simple hide in the absence of the necessary
environmental features. Then I simply don't have to think about it
usually.

See what I mean about bloat?  Imagine an API with thousands of methods
doing something like this for each one.  It wouldn't be feasible on theWeb.

Well an API with thousands of methods would scare me much more than
this code. Even jQuery's large API has fewer than 250 methods in it.

Yes, for a small Intranet app, you could certainly get by with the above
(depending on its performance requirements of course).

Why don't you think this would scale to the multiple environments of
the Internet?

Not that I know of.  :)

So it looks like you have some selling to do! :)

-- Scott
 
D

David Mark

Scott said:
Do you centralize all code that might need rounded corners, then?

I don't think this is a good example feature as it is hard to imagine
code that hinges on rounded-corners. But yes, depending on the
complexity of the applications, you may need to break it up into
sections and use a different gateway for each section.
If
so, how do you deal with dynamic changes to the DOM? Or do you store
a variable with the result of API,roundCorners? If it's that, how
much savings do you really get?

I don't follow. The gateways prevent entry to sections that would rely
on that feature.
Of course, but my whole post was about ways to make a static API
available that doesn't blow up or fail silently even in the absence of
features we would like.

Well, you can't really abstract a random environment with a static API
unless you are willing to allow some functions to fail silently (which
can work in some cases).
Unless I actually can note performance issues, I'm much more concerned
with clean APIs that are as easy to use as possible than I am about
bloat in the library code.

You can't get much cleaner than the method I describe. If the feature
is there, it is expected to work (and vice-versa), so all you have to do
is write an appropriate gateway (or gateways) for your app. As for the
API itself, the described technique lends itself well to one-off method
function creation, which leads to a clean and efficient set of methods.
But if performance is a concern, this can be done efficiently. It can
still be an up-front check:

API.myCoolFade = (API.opacitySupported)
? function(elt) {
// cool opacity animation here.
}
: function(elt) {
if (elt) elt.style.display = 'none';
}

But now you have an extraneous flag for each dynamically created
function. Why not just use the functions themselves as the flags? Then
there is nothing to get out of sync.
I certainly agree that a dynamic API can be more flexible; that's
practically tautological. I'm not sure I agree about the efficiency
question. To me the main question is whether the behavior of the
static API can degrade in a reasonable manner in environment that
don't support its full functionality.

It is more efficient because neither the app nor the API functions have
to continually check for features or waste time calling code that falls
through silently.
I've done that.too. It works fine. The trouble is then if there is a
simpler supported version of the functionality with fewer bells and
whistles that I can fall back on. It's nice to have the super-cool
fade fall back on a simple hide in the absence of the necessary
environmental features. Then I simply don't have to think about it
usually.

Sure, do that at the application level. If the fade effect is there,
define a hide/show function that uses it. Otherwise use the stock
hide/show function.

if (API.effects && API.effects.fade) {
myCoolShowFunction = function() { ... };
} else {
myCoolShowFunction = API.showElement;
}

Note that this is a generic example. It is not specific (but is
similar) to My Library, which actually does something like this
internally. As a matter of fact, as it sits, My Library's show/hide
functionality is less than ideal as it actually does ignore effects
options on hide/show when effects are impossible. But when only
_specific_ effects are unavailable (e.g. fade), it is up to the
applications to avoid passing those effects functions in the options.
That's something I need to rearrange down the road. For now the
incongruity is simply documented. There actually is a flag on the
affected methods indicating whether the hide/show operation will be
immediate or progressive (the latter indicating that a callback can be
used). Affected methods include setElementHtml, changeImage, as well as
showElement and a few others that can optionally use effects and/or a
callback.

The effects stuff is a bad example though as effects in general will
virtually always be possible (all they need is CSS support and
setInterval). The fade effect may be unavailable in some ancient and/or
limited browsers, but that would be rare compared to something like XHR.
And it is hard to imagine an application that would actually _need_
effects at all, so other than checking for specific effects like fade,
it is fine for most applications to remain oblivious to their presence
or absence.

Of course, when using the OO interface, it is as simple as:-

var E;

if (E && E.prototype.fadeIn) {
// OO application that _must_ be able to fade in elements
}
Well an API with thousands of methods would scare me much more than
this code. Even jQuery's large API has fewer than 250 methods in it.

Large is relative. jQuery isn't much more than a haphazard query engine
with a few basic (and broken) DOM wrappers thrown in. Where they are
starting to bloat is the ill-advised "Live" feature, which attempts to
bottle event delegation (again it is about marketing rather than
providing a sound API). Also, they combine getters and setters, which
reduces the number of methods, but makes application code virtually
unreadable (you must count the number of arguments passed to
differentiate between get and set operations).
Why don't you think this would scale to the multiple environments of
the Internet?

In short, too many flag checks in the application code. Virtually
everything would require such checks as nothing is assured on the
Internet. It's much simpler (and more efficient) to detect methods of
the API up front and be done with it.
So it looks like you have some selling to do! :)

You mean as far as examples of people using My Library. There are
several people building applications with it that I know of (and likely
many more that I don't know of), but it is only a couple of months in.
I think that if I continue to improve the documentation and wrap up the
last of the CSS3 selectors that everyone seems to expect these days, it
will sell itself. If something like jQuery can become wildly popular,
despite outrageous shortcomings and inefficiencies, I think it is only a
matter of time for mine to do the same.

I'm not much for selling though. As I've said repeatedly, the best bet
is to avoid general-purpose libraries altogether. But I suppose if you
are already sold on the strategy, mine has a lot of positives that
aren't found in any of the others (starting with the dynamic API and
ending with the support that I provide). Also, there is the fact that
none of the others can do much of anything without browser sniffing (in
one form or another). All but jQuery (which uses bad object inferences
and bogus feature testing) are still fixated on the UA string, which is
clearly a fatal flaw (and has been for a decade). They don't see it as
fatal as to them it is sane to swap out a huge script every time a new
browser comes out (and to ignore all that came before). But the
end-users won't buy (or even understand) that when their favorite sites
break (they'll just get new favorites).
 
D

David Mark

David Mark wrote:

[...]
Note that this is a generic example. It is not specific (but is
similar) to My Library, which actually does something like this
internally. As a matter of fact, as it sits, My Library's show/hide
functionality is less than ideal as it actually does ignore effects
options on hide/show when effects are impossible. But when only
_specific_ effects are unavailable (e.g. fade), it is up to the
applications to avoid passing those effects functions in the options.
That's something I need to rearrange down the road. For now the
incongruity is simply documented. There actually is a flag on the
affected methods indicating whether the hide/show operation will be
immediate or progressive (the latter indicating that a callback can be
used). Affected methods include setElementHtml, changeImage, as well as
showElement and a few others that can optionally use effects and/or a
callback.

Actually, checking my documentation, I made that sound more complicated
than it is, at least for showElement. Unless you consider environments
that are lacking setInterval, the ability to do progressive hide/show is
known at _build_ time (as it should be) as the showElement method itself
would be pruned in environments lacking CSS support. As noted in the
docs, this is not the case for setElementHtml and a few others, which is
something I do need to address. You should be able to determine the
capabilities of these methods at build time (at least as far as the
callback goes) and not have to check the (async) flag property at call time.
 
S

Scott Sauyet

I don't think this is a good example feature as it is hard to imagine
code that hinges on rounded-corners. But yes, depending on the
complexity of the applications, you may need to break it up into
sections and use a different gateway for each section.

I'm not feeling very well and don't have the energy to respond to this
whole interesting post, but I do want to follow up on this point.

I'm not sure how you combine your gateways. If you have multiple
features being used for one block of code, it's of course
straightforward to do this:

var myForm = /* ... */,
myElt = /* ... */,
myContainer = /* ... */;

if (API.attachEvent &&API.validateForm && API.xhr &&
API.cloneElt && API.appendElt && API.roundCorners) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
API.roundCorders(newElt);
},
error: function(msg) {/* ... */}
})
}
});
}

But to my eyes there's something wrong with this code. I really want
to run everything else even if rounded corners are not supported.
That's just a nice tweak. Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed, but you seem to be saying that these should all go at a
very high level. What am I missing?

-- Scott
 
D

David Mark

Scott said:
I'm not feeling very well and don't have the energy to respond to this
whole interesting post, but I do want to follow up on this point.

I'm not sure how you combine your gateways. If you have multiple
features being used for one block of code, it's of course
straightforward to do this:

var myForm = /* ... */,
myElt = /* ... */,
myContainer = /* ... */;

if (API.attachEvent &&API.validateForm && API.xhr &&
API.cloneElt && API.appendElt && API.roundCorners) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
API.roundCorders(newElt);
},
error: function(msg) {/* ... */}
})
}
});
}

But to my eyes there's something wrong with this code. I really want
to run everything else even if rounded corners are not supported.
That's just a nice tweak. Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed, but you seem to be saying that these should all go at a
very high level. What am I missing?

Join the club on not feeling well. Briefly, you aren't missing
anything. There are exceptions to every rule.
 
I

Ivan S

Join the club on not feeling well.  Briefly, you aren't missing
anything.  There are exceptions to every rule.


Well, I suppose one could call "API.roundCorners" function (and do
feature test) at the time of creating element (var myElt = /* ... */
<- here, I suppose), so that "API.cloneElement" would return element
that already has rounded element (or not, if feature is not
available).

This approach seems better to me, since there is separation of concern
(Ajax - styling).


Any thoughts about this? :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top