jQuery Forum

Now that I ran into the issue again I'm going to revive a bit of an old
thread of mine.
Extensibility: Extending init selectors to support application objects
http://groups.google.com/group/jquery-dev/browse_thread/thread/c0743849212a360a/f797c0d2f54dd9cc
The gist of the thread is talking about a feature letting you extend
jQuery to handle custom objects properly.
ie: If you have a Widget system in your app, you could extend jQuery so
that $(widgetObject) and $(this).append(widgetObject); are smart enough
to know how to handle the widget object (ie: Grabbing the proper dom
note for the widget).
Originally the discussion stopped because someone noted that you could
override jQuery.fn.init with a proxy method to achieve this ability.
I was doing some work today on our the version of the app the company I
work for is building, and after spending some time tracking down a bug I
ended up finding that it was caused by the fact that overriding .init
actually doesn't handle this feature properly.
.append(obj); goes directly into domManip and never makes it's way to
init, so as a result this feature does not work. At the moment I'm
working around this by hacking jQuery.clean with an extra, ugly proxy
method. But either something has changed in jQuery since that time then,
or this never worked from the start.
This considered, I think this feature in one of three forms would be good:
- Things which go directly to domManip make their way to init at some
point so overriding it will work.
- Making jQuery understand a callback name which it can look for in
custom objects. ie: Add jQuerySelectCallback or whatever to your
Widget's prototype and jQuery will use that to select the node.
- The proposed feature of having a callback list jQuery understands
which is used in init, and wherever else necessary to allow for this
feature to work.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--

I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki, so you can see the history of editing)
Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a
way to find out why IE is breaking /sarcasm) I've narrowed it down to
$button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls
.clean which near the end calls fragment.appendChild( ret[i] ); fragment
is the document, and i is 0, ret is 3 items in length containing the
text node, span, and other text node. jQuery tries to appendChild to the
document and IE decides it doesn't like it.
Does this seem like a jQuery bug?
Note: ya, I have tried splitting the append call into three separate
ones, still causes the same issue on the first one.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

I'm working on a patch to jQuery to make it so that initialization can
support application specific objects through extensibility.
The use case is in applications where you have your own meaning for
certain parts of the system. For example, a Widget system. Your app has
a class "Widget" and you use these Widget objects a lot. The case here
is that you want $(widgetObject) to know how to extract the node for the
Widget object so that jQuery can manipulate it.
Currently I'm using jQuery.fn.init.callbacks for the callbacks, I'd like
to have some input on what API is actually desired.
An extremely simple example use:
function Widget(id) {
this.id = id;
}
jQuery.fn.init.callbacks.push(function( selector, context ) {
if( selector instanceof Widget ) {
return "#widget-"+ selector.id;
}
}):
jQuery(function($) {
var myWidget = new Widget('aaa');
$(myWidget).css('backgroundColor', 'red');
});
The current defined API is about the format of the callbacks:
* Callbacks return the selector and context passed to the jQuery object.
* Callback should check the selector and see if it is a object it wants
to mutate.
* If mutation is desired the callback should give a return value.
** Callback may return an array of dom nodes to be used...
** or, callback may return a string that will be used as a selector by
jQuery to find the dom nodes.
As you can see in the code above, it checked if the selector was a
Widget object, since it was it returned a string selector which jQuery
turned into a dom node. In this example the application just organized
it's Widgets in the Widget object with a setup where each Widget had an
id of the widget's id prefixed with "widget-".
So I'd like some input on what the desired API is. And any other ideas
of what other functionality people can come up with where application
objects should be handled. Currently I'm verifying that $(myWidget); and
$('<div/>').appendTo(myWidget); work.
Just to head off anyone suggesting workarounds. I don't post to the dev
list cause I'm interested in alternate less capable ways of doing
things, I post because there is functionality I'm interested in (and
most of the time, willing to help program the implementation for). I
already know you can hack your way around in your own Widget object to
try and create jQuery objects or whatever but that is not what I am
trying to do, I'm trying to make integration of jQuery into applications
easier.
For another note to anyone suggesting a proxy method (overriding
window.jQuery), that does not work. I can confirm that if you try that
technique this:
jQuery(function($) {
$(myWidget);
});
Will not work. And neither will this:
$('<div/>').appendTo(myWidget);
Because jQuery isolates itself inside of a closure to make sure that
overriding the jQuery method will not break jQuery on it's own from working.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

When I wrote my framework at work with a .bind method similar to jQuery
I actually ended up adding another simple way to call it thinking jQuery
supported it.
$(node).unbind(); // everything
$(node).unbind('type'); // all events of type
$(node).unbind('type', func); // just the func event on type
$(node).unbind(func); // func on all types; not supported by jQuery
It's another useful call. I actually use it a fair bit at work since
it's about as short as helper methods:
function someClickEventFunc() { ... }
$(node).click(someClickEventFunc);
$(node).unbind(someClickEventFunc);
Worth an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

At work when I was writing my own JavaScript framework (partly inspired
in API by jQuery) I ran into a number of times where I needed to grab a
series of css values and set them all onto another, as a result I ended
up coming up with another type of input to .css;
$(someNode).css(['backgroundColor', 'backgroundImage', 'width', 'height', 'position', 'top', 'left']);
Basically I made .css accept a single array of property names to grab.
The return is a object with property keys and values set on them. The
absolute beauty of this, was that you could take that same object and
set it onto another note, or even use it to revert.
var cssCache = $(node).css(['display', 'width', 'height']);
// Do a bunch of stuff to node that modifies all that kind of css.
$(node).css(cssCache); // Revert to the original values
Though I do take note now, another possibility which might fit in better
with .addClass and .bind might be something like.
$(someNode).css('backgroundColor backgroundImage width height position top left');
Though the fact that the difference between 'width' and 'width height'
is the difference between .css returning a string or an array, so it
might be worth it to use the array input format to avoid confusion.
Any thoughts? This worth opening an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

At work I tried to animate something to grow horizontally then grow
vertically.
.hide().css({height: 5}) // Use a small initial height so the growing can be seen
.animate({width: "show"})
.animate({height: "show"});
The second half of the animation of course does not work because show
only animates a non-shown value to it's natural state.
I do not believe there is a proper way (besides doing ugly manual
calculations and basically duplicating some jQuery internal tricks
outside of jQuery) to smootly animate something to it's natural state.
Perhaps we could use something like a new "natural" option.
.hide().css({height: 5}) // Use a small initial height so the growing can be seen
.animate({width: "natural"})
.animate({height: "natural"});
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

I'm wondering what kind of tricks and setups other people have when they
are developing with jQuery.
Be it writing some improvements to jQuery itself, or writing a plugin.
I'm not really looking for those using jQuery in an application, cause
that environment is normally just taking a few jQuery files and plugins
and including that into your existing development environment.
I'm trying to find out how people (plugin and core jQuery developers)
normally handle their development environment for working on jQuery or a
jQuery plugin.
Every time I work on another piece for jQuery, I end up creating a new
html file, which normally consists of either copying some junk from
another project and modifying it, or constructing a new one by grabbing
a doctype and a few tags off some references on the internet. I also end
up grabbing jQuery again to shove in and include.
As for actually testing stuff, I normally might just go off the
filesystem, however sometimes that doesn't quite work right, and I end
up needing to configure a local webserver (normally I just edit the
config for my local nginx).
Things get real ugly when working on patches to jQuery core itself.
Mostly because of needing to `make jquery` all the time. Sometimes I end
up sitting there for a few minutes trying to figure out "why the hell
didn't my edit fix this bug?" then realize I forgot to rebuilt jquery
before I refreshed the page to test it.
All in all, I don't really consider it a nice and clean, or even helpful
environment.
For that reason I've actually started experimenting with building a
Rails app to manage projects and streamline things like creating html
pages from templates, previewing a page and working on code live, as
well as nice integration for github forks of jQuery (fork/clone as in
gitspeak), jQuery svn, and different versions of jQuery.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

I've been thinking about my 4query offsite branch and the merits of
something more tied to jQuery.
A project more involved with jQuery definitely has the advantage of
being much easier to keep compatibility and avoid the code differing to
much.
jQuery has strong policies on things being compatible with all browsers,
and a number of other things wouldn't fit in jQuery itself right away.
What about something like a jQuery Labs project. The project could work
on experimental, and preemptive features. Things like HTML5 stuff,
partially standardized / implemented features, making a lot more
internals transparently extensible, modularizing the code and supporting
a jQuery.ui like system for bundling jQuery, and various other ideas
people could suggest which could be worked on.
I actually have half the code for a module that adds borderRadius css
support (All the css.get code, working on the css.set). It adds a
interface that follows the w3 draft, works in Gekko and Safari, and
gracefully falls back in other browsers. It's also future compatible so
if you're using .css({borderRadius: 10}); now it'll still work in a few
years when browsers fix up their implementation of the spec (FF doesn't
support irregulars, Webkit doesn't let you get borderRadius on it's own;
and neither of them understand the "horiz / vert" syntax in the spec now
that the ambiguity has been resolved) and implement real borderRadius
support rather than vendor extensions.
Originally I was going to directly support it in the library, but after
working for awhile making it fully compatible the code is about 2-3x the
size of the code for opacity via filter support. So instead I setup a
fairly nice method of making it possible for plugins to implement this
kind of extra compatibility where desired.
Things like borderRadius would probably become part of an optional
compatibility module which the bundler would let you pick if included or
not.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.org)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

I just did a little check after noticing something while developing. But
.css('margin'); and .css('padding'); are fairly inconsistent, could be
considered buggy even.
Issue is present in both 1.3.2 and 1.2.6
Test case uploaded to:
http://test.4query.org/combined-css/
I've tested in Firefox3, Midori (WebKit browser), and Opera 9.64, test
case output for them:
Firefox: http://test.4query.org/combined-css/firefox.html
Midori: http://test.4query.org/combined-css/midori.txt
Opera: http://test.4query.org/combined-css/opera.txt
Firefox outputs "t r b l" form whenever it has the data, while midori
and opera output the shortened combined value form.
Firefox and Midori both do not report margin/padding when defined in a
style tag instead of on .style; However they do report marginLeft (style
was defined like #a { margin: ...; })
Opera is the only one that reports margin/padding when defined in a
style tag.
If it's something we want to fix, it should be easy to handle by mapping
margin/padding or whatever combined formats to queries for the four trbl
values and combine them together.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.org)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

I've mentioned my little fork project on the list a few times before,
I've finally written a bit of a report on the goals in the project. I
think it's probably missing some stuff, but it definitely explains a bit
more. I never really noted how the project relates to the project at
work, and there are more improvements and rationales to detail. But for
now it's a good start.
http://code.google.com/p/js4query/wiki/Report
I'd appreciate it being looked over and commended on, especially by John
since it would be nice to do as much of the goals and improvements as
possible inside of jQuery itself instead of in a fork.
Currently I think I got the trunk to a moderately usable point. Right
now I was just merging updates from jQuery in and trunk@6256 made a bit
of a conflict with the jQuery/4query object separation, so I'm merging
it and will push those updates once I integrate the improvements together.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)

Both Mozilla and WebKit have built support for border radius (meaning
now only IE and Opera should be left without this kind of feature):
Mozilla with -moz-border-radius and -moz-border-radius-topleft
WebKit with -webkit-border-radius and -webkit-border-top-left-radius
As well there is a w3 working draft standardizing border-radius and
border-top-left-radius.
http://www.w3.org/TR/css3-background/#the-border-radius
I'm considering writing a patch to jQuery (that can be committed into
trunk) to enable support for a cross-browser border-radius in .css().
ie: .css({borderRadius: 10, borderTopLeftRadius: 15});
The question here. Is should I enhance $.support with tests for
border-radius, -moz-border-radius, and -webkit-border-radius or should I
just have .css borderRadius set all 3 versions at once?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

Before I go and write one of my own. Does anyone know of any good
JavaScript color library written?
For an idea of the scope wanted, here's the plan I'm hoping for (Ideally
I may be writing this for use at work inside of multiple parts of the
system):
The first half is generic management of colors. ie: conversion between
RGB/HSV/CMYK/etc... color spaces as well as color matrix transformations
Hue/Brightness/Temperature/etc...
I'll likely use that as a backend as well in the color picker used at work.
And the second part is the more usable portion meant for use in more
than just simple color picking and advanced color transformation.
The idea is the generation of random colors (along a limited brightness
range) as well as generation of colors with a bit of an offset in
brightness.
Think dynamic editing applications. Creating a dark transparent overlay
and then creating a few boxes with random color themes (random
background colors with borders using a little darker of the same color).
Of course, ideally this could be thrown into a jQuery plugin then to
allow easy generation of containers using various or random color schemes.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

I don't know if anyone thought of it, but how about adding another
method of calling .css?
In my own framework I allow a call such as:
pf('#foo').css(['backgroundColor', 'color', 'borderLeftColor']);
And the call will output an object with that information (keys as the
style keys, and the values of those are the current css values.
It's actually fairly useful, as you can use it to generate an object
containing current css information, then use that to revert styles back
after you've changed something.
Also a small note on the jquery.color plugin. Has anyone thought of
supporting borderColor in it? I know the individual edges are supported,
but it would be nice if it supported the generic css property to animate
all 4 sides at once without specifying them individually.
It's actually fairly easy to do, just take this method:
jQuery.fx.step[attr] = function(fx){
if ( fx.state == 0 ) {
fx.start = getColor( fx.elem, attr );
copy the function and turn it into a generic below:
function step(fx, attr){
.....
Then turn the old one into a call like:
jQuery.fx.step[attr] = function(fx){
step(fx, attr);
}
After that one simple addition:
jQuery.fx.step.borderColor = function(fx) {
step(fx, 'borderTopColor');
step(fx, 'borderRightColor');
step(fx, 'borderBottomColor');
step(fx, 'borderLeftColor');
};
Of course, I have a feeling that someone actually adding it could easily
create a better performing one that actually handles .borderColor
separately by grabbing the actual borderColor (rather than individually
animating the four corners) and splitting the value up.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)

I have a function similar to the .closest method in jQuery inside of
my framework. I was wondering if it was a good idea to have .closest
accept am optional second argument (restriction) to it like my own.
In my framework I use pf.trace (tracing backwards through the dom)
almost precisely the same as .closest;
pf('#foo').click(function(e) {
var elm = pf.trace(e.target, 'li', this);
if(!elm) return;
...
});
The third argument is a restriction. You can basically read that as
"trace backwards through the dom starting at e.target and return the
first li tag found, don't return any node if you hit 'this'.
The third argument is a restriction so basically in a case like:
<ul>
<li>
<ul id="foo">
<li>...</li>
<ul>
<li>
</ul>
If you clicked on the ul#foo instead of the li inside of it (things
like that are quite possible after you've done styling) then just
using .closest('li') will return the parent li which you don't want.
Another argument could serve as a restriction to the check.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
What is the accepted method of dom manipulation in jQuery (creating and
inserting new dom nodes).
I can't seam to find a reasonably intuitive method of doing this using
jQuery internals.
A good example. Given a jQuery object which contains a ul tag. How
would one insert a new li tag, and then insert some user specified <b>TEXT</b>.
With emphasis on it being text, for the li, not some random html. The
standard use case of this, is "given a ul tag and an array of data,
inject a number of li tags containing that data".
In my own framework at work the methods like append (while they do
accept dom nodes and other objects) have the primary purpose of
creating an injecting new nodes. The first argument to them is a tag
name and they also accept an object of attributes.
So for that example:
<pre>var list = ['foo', 'bar', 'baz'];
var ul = pf('#myul');
list.forEach(function(data) {
    ul.append('li').text(data);
});</pre>
So the question is, "How does one do something like this in jQuery?"
((Btw: My framework does include a compatibility layer for the moz
methods like forEach; I'd probably include those in any other work as
well anyways))
I noticed that jQuery's append does handle XHTML style input (and it
parses it on it's own instead of going through innerHTML by the looks
of it; a plus for me), however the following does not work as one might
expect:
<pre>var list = ['foo', 'bar', 'baz'];
var ul = $('#myul');
list.forEach(function(data) {
    ul.append('<li />').text(data);
});</pre>
That would be because the .append returns the object containing the ul
not the new li.
And note, I do not consider the following to be an acceptable robust
method of manipulation; The data is user supplied so it shouldn't be
inserted in a place where it could be considered html, it looks fairly
unclean imho, and it does not extend past the simplest of acts because
you still cannot use anything like .attr or whatnot to further
manipulate the data:
<pre>var list = ['foo', 'bar', 'baz'];
var ul = pf('#myul');
list.forEach(function(data) {
    ul.append('<li>'+data+'</li>');
});</pre>
Also being required to run another method just to chain with something
you just created isn't an acceptable robust method. As well if I have
to go calling document.createElement then there is little point in
using jQuery for this in the first place.
So is there another robust method I am missing, or any suggestions for
robust methods which could be developed as improvements?
<pre class="moz-signature" cols="72">--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [<a class="moz-txt-link-freetext" href="http://nadir-seen-fire.com">http://nadir-seen-fire.com</a>]
-Nadir-Point (<a class="moz-txt-link-freetext" href="http://nadir-point.com">http://nadir-point.com</a>)
-Wiki-Tools (<a class="moz-txt-link-freetext" href="http://wiki-tools.com">http://wiki-tools.com</a>)
-MonkeyScript (<a class="moz-txt-link-freetext" href="http://monkeyscript.nadir-point.com">http://monkeyscript.nadir-point.com</a>)
-Animepedia (<a class="moz-txt-link-freetext" href="http://anime.wikia.com">http://anime.wikia.com</a>)
-Narutopedia (<a class="moz-txt-link-freetext" href="http://naruto.wikia.com">http://naruto.wikia.com</a>)
-Soul Eater Wiki (<a class="moz-txt-link-freetext" href="http://souleater.wikia.com">http://souleater.wikia.com</a>)
</pre>

Has there been any thought, discussion, or interest in providing
jQuery as a backend, or being able to provide another library as
another API to jQuery.
jQuery is quite mature (even though a bug I couldn't track down forced
us to discard use of it at work), but one of the things that has irked
me repeatedly is small commonly used parts of the API. Namely show/
hide, toggle, end, and sometimes I've thought the bind/live...
separation could be done better.
Of course even if the API could be done a little different in a way
that made sense a little more that's not a good reason to actually
change the jQuery API. One of the nice things of jQuery is that for
the most part the API has changed very little. The massive differences
of 3 versions of MooTools at work in the system built before I came in
were very annoying.
Beyond rolling a library as a modified API using jQuery as a backend
does have potential use elsewhere. One of the special things about the
system I have at work is that the JavaScript framework being used
(since it's part of the system) can do nice things like taking a
Widget object as input, and knowing how to handle the actual nodes
it's associated with.
If you were wondering what irked me a bit, it was primarily show/hide.
$('#foo').hide(); does have the connotation of hiding something.
However it always annoyed me how 'hide' was actually a very specific
"scale diagonally to the upper left, and disappear". Rather than a
simple 'hide me' like it implies.
And for just sliding something closed, $('#foo').slideUp(); is used,
even though 'slideUp' is basically a type of 'hide' with a different
animation. While over on the other hand to actually 'hide' something
without animation (I have had to do this many a time) I have to
verbosely type in $('#foo').css('display', 'none');
It honestly makes much more sense to me if:
$('#foo').hide(); just set display: none;
animating something to slide shut was $('#foo').hide
({animate:'slideup'});
and if you actually wanted .hide() to animate you would tell it to
have a default:
$.defaults.hide.animate = 'slideup';
Basically the thought I've had is. "Keeping code short and sweet is
nice, but only if you do it without losing information. Sometimes you
go to far in shortening the size of code, and end up losing
information that makes it readable."
Along with that 'toggle' irks me as well. For the very well integrated
jQuery user, "Huh, 'toggle', that just flips my visibility.", but for
anyone that is just looking at the code "Toggle? What does it
toggle?". Toggle could flip a checkbox, it could show or hide
something, if it shows or hides something then how does it do it? does
it slide, does it fade, or does it just disappear?
Honestly toggleVisibility working like the .hide I mentioned above
makes more sense to me.
The last one, not really an irk, but just something I've thought could
be cleaner. Rather than .bind, .live, and whatever for binding
different types of events. To me this makes more sense:
$('#foo').event('mouseover', function(e) {...}); // A mouseover event
bound to #foo
$('#foo').event({
mouseover: function(e) {...},
mouseout: function(e) {...}
}); // a mouseover and mouse out bound to '#foo'
$('#foo').event('a', 'click', function(e, elm) {...}); // A click
event bound to '#foo' that event delegates to anchors.
Ideally in an event delegation case 'this' would be a jQuery object
with the delegated target.
Thus: $('#foo').event('a', 'click', function(e, elm) {this.hide
({animate:'fade'});});