Re: [jQuery] http://www.acko.net/blog/jquery-menu-scout -- jQuery Menu Scout
saw this today, about jquery on drupal.org! And here's an actually useful mail about this: it's a tool that uses an ajax live-search to fetch matching pages in the Drupal Administration UI (back end). It then dims the page and highlights any links that lead directly or indirectly to the results, with a nice styled bubble. The idea is to make it easier to learn how the Drupal UI works and where certain settings are located. Video at: http://acko.net/files/Drupal%20Menu%20Scout.mp4 Clickable link to blog post: http://www.acko.net/blog/jquery-menu-scout Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Efforts to Convert Folks to jQuery
I don't have time to sift through this thread, but I just want to say I gave a talk about Drupal jQuery twice in September and got nothing but good replies. The slides are online. Mail me if you want the Apple Keynote file: http://www.acko.net/blog/jquery-drupalcon-talk There is also a video on Google Video, search for jquery drupalcon or so. My slide about why jQuery? says: jQuery •Doesn’t mess with the language (Prototype) •Doesn’t try to be Python (Mochikit) •Only essentials: 15KB (Scriptaculous, Dojo) •More than cosmetic effects (Moo.fx) •Makes common tasks easy :) Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Handling unsupported browsers
Does anyone have a preferred way for handling browsers that are not
officially supported by jQuery, such as Netscape? What I am planning
on doing is having server-side browser detection code which gives me
the browser name, platform, and version number, then in my site,
having each page coded in two different ways: one for Ajax and one
without Ajax. Is this what other people do?
Server-side browser detection is unreliable due to User Agent spoofing.
It's much better to just code your pages so that the JavaScript
features are tacked on transparently, and have a usable alternative
when JavaScript is turned off. That way, you can treat any broken
browser as one which does not support JavaScript.
You can use several tricks to do this in a relatively seamless way:
1) Define a global variable jsEnabled or something, which checks
for required DOM functions. For example:
var jsEnabled = document.getElementsByTagName
document.createElement document.createTextNode
document.documentElement document.getElementById;
Then, you can augment this with browser-specific denials if there are
still problems.
2) In the global scope (NOT in .ready()), you set a class on the
html element:
if (jsEnabled) {
document.documentElement.className = 'js';
}
3) Then, you define a bunch of CSS rules with the ancestor selector
html.js (e.g. html.js #myelement) where you apply the required
styles for JavaScript-based features. This can include hiding
collapsed section of the page, making Ajax widgets visible, etc.
4) Any additional changes that need to be made to the source document
are done in $(document).ready(), but also only if (jsEnabled) is true.
This gives you the best of both worlds: you avoid non-JavaScript
users seeing useless widgets on the page or having inaccessible
content, while JavaScript users don't see the page change drastically
as soon as it finished loading. Remember: even with $(document).ready
() there is the possibility of incremental rendering.
Then, when you tell your users to turn on JavaScript or switch
browsers, it's not an ultimatum: it's a choice for them, if they want
a better user experience, but they can't still see and use your site.
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] Radio button bug
I've found a rather tricky bug in jQuery 1.0.2. When you use an animated slideDown() or show() on an element containing one or more radio buttons, the radio buttons lose their selection status in Firefox (1.5 and 2.0 for sure, maybe others), and Opera 9 (maybe others). It works fine in IE6 and Safari 2. This also only seems to happen when you apply an animation for the first time. I have attached a minimal test case to reproduce. There are four pairs of radiobuttons, each having one radio button selected. Their source markup is functionally identical. Clicking the provided link runs a different animation on each radio button pair: the first two pairs of radio buttons lose their selection, the last two work fine. This is caused by the code in jQuery.css() used to measure the dimensions of elements that are hidden. jQuery temporarily replicates the element inside its parent. This causes two selected radio buttons with the same 'name' to appear in the form, which is not allowed. It seems that Firefox and Opera defensively remove both selections in this case. One fix is to simply remove the checked attributes of all radio buttons inside the clone, before inserting it into the parent. See attached patch. This is a major blocker for jQuery in Drupal by the way, as it can break any animated portion of a form. I'm going to patch our included copy after you guys review this patch (we have a release candidate coming up next monday), but it would be nice to see this fixed in a 1.0.3 release soon ;). Steven Wittens jquery-radio-bug.patch Description: Binary data Title: jQuery Radio bug Problem: when using some animations on an element containing one or more radio buttons, the radiobuttons will lose their selection in Firefox and Opera, the first time the animation is applied. Click to trigger bug slideDown: Buggy animated show: Buggy fadeIn: Not Buggy instant show: Not Buggy ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] Replying to threads
Note.. please don't reply to existing threads when you're starting a new one. You make it harder to read mail for those of us with threaded mail-clients, as well as in the mailinglist archives. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery API discussion
The feasibility of 'namespacing' hasn't been brought up yet - but leave it to be said that it would be really really difficult and add a ton of overhead to the jQuery base as a whole (in order to continue chainability support). Err... I made a rather concrete proposal for how namespacing could be implemented in my mail of 15 october. But no-one replied to that part :/. Essentially, I think namespacing is preferable to prefixing because you don't need to repeat namespaces: i.e. $(...).onLoad().onMousemove().onClick().domAppend().domWhatever(); vs $(...).on.load().mousemove().click().dom.append().whatever(); This sort of chainability is quite intuitive, and I think it is possible to achieve. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] åäö doesn't work with load/loa dIfModified
OR you can see if IIS has a place to set the encoding, (as Apache does system wide, site wide, or directory wide). What this comes down to is changing this HTTP header: Content-Type: text/html into Content-Type: text/html; charset=ISO-8859-1 I have no clue how to do that in ASP.net though. The meta tags for html documents are only a fallback for the real HTTP headers. HTTP headers always take precendence over meta tags. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Variable from PHP to Jquery
Here's a little snippet which can help... it takes any PHP variable
and translates it into its JavaScript equivalent. Taken from Drupal
(GPL license). The HTML-safe embedding of strings is there to avoid
problems when returning JSON through iframes, you probably won't need
that.
Also to avoid having to use templated JS, we have a transparent
mechanism for passing data from PHP to JS. All you do is call an API
drupal_add_js(), which aggregates all variables that it is passed,
and automatically inserts them as a single inline script tag in the
HTML head, as Drupal.settings = { ... }. This works really well:
you don't need to dynamically generate .js files, and you avoid large
chunks of inline code.
/**
* Converts a PHP variable into its Javascript equivalent.
*
* We use HTML-safe strings, i.e. with , and escaped.
*/
function drupal_to_js($var) {
switch (gettype($var)) {
case 'boolean':
return $var ? 'true' : 'false'; // Lowercase necessary!
case 'integer':
case 'double':
return $var;
case 'resource':
case 'string':
return ''. str_replace(array(\r, \n, , , ),
array('\r', '\n', '\x3c', '\x3e',
'\x26'),
addslashes($var)) .'';
case 'array':
if (array_keys($var) === range(0, sizeof($var) - 1)) {
$output = array();
foreach ($var as $v) {
$output[] = drupal_to_js($v);
}
return '[ '. implode(', ', $output) .' ]';
}
// Fall through
case 'object':
$output = array();
foreach ($var as $k = $v) {
$output[] = drupal_to_js(strval($k)) .': '. drupal_to_js($v);
}
return '{ '. implode(', ', $output) .' }';
default:
return 'null';
}
}
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] $.ajax API change 1.0.2?
It seems that the 'success' callback of $.ajax was changed to accept
as its first argument the actual parsed data rather than the xmlHttp
object, in 1.0.2? This behaviour broke several Drupal features when I
upgraded it to jQuery 1.0.2...
We should really avoid such API changes in the future, or bump up the
middle version digit instead. In jQuery, the line between what is a
private function and what is an API call is indeed blurred (so
guaranteeing compatibility across versions for everything is near-
impossible), but it would be nice if this stuff was at least
documented. I looked around and can't seem to find any mention of
this on the 1.0.2 release notes or on this mailing list.
In Drupal, we document all API changes on a page with before/after
examples. If you build such a page when you commit changes to the
repository, it's not that much work.
Here's a snippet to document this change (if I got it right):
== $.ajax callback changed ==
In jQuery 1.0.2, the first argument to the 'succes' callback has been
changed to return the actual data rather than the XMLHttpRequest
object. Use the 'dataType' argument to $.ajax to control how the data
is returned. Note that jQuery can now parse XML, JSON and JavaScript
for you this way.
// jQuery 1.0.1
$.ajax( {
success: function (xmlhttp) {
// do stuff with xmlhttp.responseText
}
);
// jQuery 1.0.2
$.ajax( {
success: function (data) {
// do stuff with data
}
);
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] $.ajax API change 1.0.2?
Yup! I noticed that too. It broke a few pages, and scared me into DEBUGGING mode, I always liked getting back the whole httpreq. Well you can still use the complete handler to get the XMLHttpRequest back, but that handler fires regardless of success or failure. You'd have to check the status argument for that. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] $.ajax API change 1.0.2?
ou! the complete handler... perhaps it just needs a little more documentation? Or did I miss it? It's documented on $.ajax... (Function) error - A function to be called if the request fails. The function gets passed two arguments: The XMLHttpRequest object and a string describing the type of error that occurred. (Function) success - A function to be called if the request succeeds. The function gets passed one argument: The data returned from the server, formatted according to the 'dataType' parameter. (Function) complete - A function to be called when the request finishes. The function gets passed two arguments: The XMLHttpRequest object and a string describing the type the success of the request. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] John's Pager Plugin?
I wrote a pager plugin to power the http://jquery.com/api/ site. It works with both numbers, alpha characters, and words. Additionally, it works on ul, ol, and table elements (with dl elements in the works). After I squish some more bugs, I'll document it and release it. For now, however, you can find it on this page: http://jquery.com/api/js/pager.js Hmm, I'd like to voice a big concern for functionality like this, as it is invisible to non-JavaScript users... Having JavaScript features which do not degrade is bad for impaired users, but it also affects search engines and their use. You cannot link to any of the later pages, and even if you could (e.g. through a #-href trick) the search engines would not see a difference between any of the pages and most likely direct you to the first page. If I do a Google search for an API function which is not on the first page, then the search result will bring me to a 'page' which does not contain my search result. I'd have to sift through the pages myself by hand (in-page search doesn't work either!). This is very bad. Slightly related... in my most recent project I'm working with an XHTML/CSS/JS design that actually uses jQuery to finish the design (by adding wrapper divs and icon placeholders and whatnot). With JS disabled, the design looks incomplete. I'm very annoyed at the designer, but unfortunately there is no time or money to redo it, so I'm stuck with it. Many jQuery users seems to suffering from if all you have is a hammer, everything looks like a nail syndrome and it worries me a bit :/. Steven Wittens ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] Revision 231 cloneNode() Firefox issue
I'm experiencing some problems on a site with some apparently simple
code. It used to work with jQuery R226, but when I updated to 1.0
final (R231), it broke in Firefox (Mac) with the following error:
Error: $(e.cloneNode(true)) has no properties
Source: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/
themes/clubhouse/scripts/jq.js
Line: 376
It works fine in Safari and possibly other browsers too.
This is in the following code from jquery-1.0.js:
jQuery.swap( e, old, function() {
if (jQuery.css(e,display) != none) {
oHeight = e.offsetHeight;
oWidth = e.offsetWidth;
} else {
//
e = $(e.cloneNode(true)).css({
visibility: hidden, position:
absolute, display: block
}).prependTo(body)[0];
//
oHeight = e.clientHeight;
oWidth = e.clientWidth;
e.parentNode.removeChild(e);
}
});
which was last changed in revision 230-231. The problem happens when
doing a plain slideDown() from inside a .click() callback:
jQuery(a.login).click(function(){
jQuery(#header-forms div).filter(:visible).slideUp(slow);
//
jQuery(#login-box).slideDown(slow);
//
...
});
in: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/themes/
clubhouse/scripts/jq-clubhouse.js
This is pretty simple jQuery usage, and it works fine with 1.0 final
in Firefox if I extract the immediate markup and try it on a stand-
alone, unstyled .html page. It is only in combination with the other
markup on that page that it breaks. It could be a browser bug, jquery
bug or something in my markup that's messing stuff up, I'm not sure.
You can try it for yourself on:
http://sgmvoc.optimistweb.org/ (click the 'Register' or 'Member log-
in' in the header)
Has anyone got any ideas about this? Have you seen it before?
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] Revision 231 cloneNode() Firefox issue
I'm experiencing some problems on a site with some apparently simple
code. It used to work with jQuery R226, but when I updated to 1.0
final (R231), it broke in Firefox (Mac) with the following error:
Error: $(e.cloneNode(true)) has no properties
Source: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/
themes/clubhouse/scripts/jq.js
Line: 376
It works fine in Safari and possibly other browsers too.
This is in the following code from jquery-1.0.js:
jQuery.swap( e, old, function() {
if (jQuery.css(e,display) != none) {
oHeight = e.offsetHeight;
oWidth = e.offsetWidth;
} else {
//
e = $(e.cloneNode(true)).css({
visibility: hidden, position:
absolute, display: block
}).prependTo(body)[0];
//
oHeight = e.clientHeight;
oWidth = e.clientWidth;
e.parentNode.removeChild(e);
}
});
which was last changed in revision 230-231. The problem happens when
doing a plain slideDown() from inside a .click() callback:
jQuery(a.login).click(function(){
jQuery(#header-forms div).filter(:visible).slideUp(slow);
//
jQuery(#login-box).slideDown(slow);
//
...
});
in: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/themes/
clubhouse/scripts/jq-clubhouse.js
This is pretty simple jQuery usage, and it works fine with 1.0 final
in Firefox if I extract the immediate markup and try it on a stand-
alone, unstyled .html page. It is only in combination with the other
markup on that page that it breaks. It could be a browser bug, jquery
bug or something in my markup that's messing stuff up, I'm not sure.
You can try it for yourself on:
http://sgmvoc.optimistweb.org/ (click the 'Register' or 'Member log-
in' in the header)
Has anyone got any ideas about this? Have you seen it before?
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] Revision 231 cloneNode() Firefox issue
(resending, the last copy didn't arrive...? :/ )
I'm experiencing some problems on a site with some apparently simple
code. It used to work with jQuery R226, but when I updated to 1.0
final (R231), it broke in Firefox (Mac) with the following error:
Error: $(e.cloneNode(true)) has no properties
Source: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/
themes/clubhouse/scripts/jq.js
Line: 376
It works fine in Safari and possibly other browsers too.
This is in the following code from jquery-1.0.js:
jQuery.swap( e, old, function() {
if (jQuery.css(e,display) != none) {
oHeight = e.offsetHeight;
oWidth = e.offsetWidth;
} else {
//
e = $(e.cloneNode(true)).css({
visibility: hidden, position:
absolute, display: block
}).prependTo(body)[0];
//
oHeight = e.clientHeight;
oWidth = e.clientWidth;
e.parentNode.removeChild(e);
}
});
which was last changed in revision 230-231. The problem happens when
doing a plain slideDown() from inside a .click() callback:
jQuery(a.login).click(function(){
jQuery(#header-forms div).filter(:visible).slideUp(slow);
//
jQuery(#login-box).slideDown(slow);
//
...
});
in: http://sgmvoc.optimistweb.org/sites/sgmvoc.optimistweb.org/themes/
clubhouse/scripts/jq-clubhouse.js
This is pretty simple jQuery usage, and it works fine with 1.0 final
in Firefox if I extract the immediate markup and try it on a stand-
alone, unstyled .html page. It is only in combination with the other
markup on that page that it breaks. It could be a browser bug, jquery
bug or something in my markup that's messing stuff up, I'm not sure.
You can try it for yourself on:
http://sgmvoc.optimistweb.org/ (click the 'Register' or 'Member log-
in' in the header)
Has anyone got any ideas about this? Have you seen it before?
Steven Wittens
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
