Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Following an involved discussion on groups.drupal.org, a critical mass of mindshare is starting to gather behind the possible integration of the jQuery javascript package into Drupal core. The questions to be answered are "should we?", "what do we gain?", "what are the risks?" and "how is it best accomplished?". We even have the author of jQuery willing to help us out.
Now let's see those patches!
Comment | File | Size | Author |
---|---|---|---|
#76 | screehshoot.png | 8.17 KB | Rok Žlender |
#74 | grippie_0.png | 218 bytes | eaton |
#70 | jquery_9.patch | 48.35 KB | Anonymous (not verified) |
#61 | jquery_8_0.patch | 48.15 KB | Anonymous (not verified) |
#60 | validation-error.png | 4.39 KB | yched |
Comments
Comment #1
Steven CreditAttribution: Steven commentedActually, I think most of those questions have already been answered in the discussion. Let's not bring all that here ;). Patches it is!
Comment #2
Frando CreditAttribution: Frando commentedI think Steven is quite right. Instead of discussing the same questions we discussed on groups, we should try to get some code working.
For the fellows who didn't follow the discussion on groups, here's a short summary:
- Why do we want to include a third-party javascript library (i.e. jQuery)?
* jQuery has features that would just be perfect for drupal, namely the really simple DOM query system (both via XPATH and CSS style queries), event system and some basic effects. It could simplify most of the common drupal js tasks a lot. It would also make it much easier to add some basic js functionality for developers who aren't too familiar with js yet (i.e. for UI improvements)
* Of course, it would be possible to develop all these feature for our current drupal.js library. However, we would need heaps of time and effort to catch up with jQuery or similar libraries. Time and effort that could be used to actually make use of js in drupal.
- Why to use jQuery and not prototype/scriptacolous/...
* jQuery is highly modular. We take only the modules we want (i.e. the query system, events, the basic effects, ajax) and can then extend these by our needs. Module developers could even provide their module-specific plugins/extensions to jQuery, so we'll have lots of code reused by having all the required flexibility.
* jQuery is small (~20k compressed).
* jQuery has a great DOM query system that eases most of the common js tasks in drupal.
* The author of jQuery (who seems to be actively interested in helping to integrate jQuery into drupal, which could be a huge plus for us) dropped some hints that he's considering to license jQuery also under a GPL licence (prototype i.e. is only available under MIT-style licences)
- What would be the disadvantages of using an external library?
* We would rely on a third-party product.
However, I think we will mainly get advantages out ofthis, as bugs will get fixed by the jQuery team and we can focus on the usage of js is drupal (usability, ui improvements) and don't have to deal too much with the library behind it.
This should just be some kind of summary, the complete discussion can be found in the drupal.js group.
I think we should not (yet) start this discussion here again but should focus on getting some patches which demonstrate the integration of jQuery into drupal ...
Comment #3
Frando CreditAttribution: Frando commentedsmall, but important typo: jQuery's compressed size is not 20, but 10kb.
Comment #4
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commented10 kb is pretty amazing for such a nice application.
Drupal.js is already 12 kb of it's own. I did have a loot at the jQuery page and it doesn't look very hard to port our current situation to jQuery methods/JS.
The only problem I see is the autocomplete.js and the upload.js, but hey... I'm not a JS-guru at all..
I think I'm gonna play with jQuery tomorrow, how about you guys? ;-)
Comment #5
kkaefer CreditAttribution: kkaefer commentedHere is a very first patch. I know that it breaks some JS functionality but this will be fixed before the patch is ready for core.
I have not yet replaced the HTTPGet/Post functions as jQuery's XMLHttpRequest model is slightly different from ours (namely, the xmlhttp object is not in the callback functions arguments).
I added some legacy functions that wrap the jQuery functionality. These probably won't be in the final patch and are just here for compatibility issues. Please use jQuery's interface directly.
Comment #6
Steven CreditAttribution: Steven commentedJust to keep you guys posted... I've been working a lot on timcn's patch. I've removed the legacy functions from drupal.js and replaced them with DOM equivalents everywhere in the other .js files.
I've also replaced a lot of code with compact jQuery-style selectors.
Finally, I prettied up some things:
If you're reading this and screaming "aaaah bloat!", well tough ;). Not only do the effects look cool, but they enhance the usability by not having jarring transitions when things change on the page. That's IMO worth having.
In spite of the extra effects and the 'wasteful' codestyle, there are still about 100 lines less Javascript after this patch (not counting the addition of jQuery of course).
There are still a couple of problems though:
I've emailed John Resig with some questions. In the meantime, here's the patch + the hacked copy of jQuery. Note that only the following part was patched:
Comment #7
Steven CreditAttribution: Steven commentedhacked, uncompressed jquery (stable).
Comment #8
Steven CreditAttribution: Steven commentedNew patch! I've developed against the newly released jQuery 1.0 alpha.
Changes:
A hacked version of jQuery is still needed (though the hacks have been submitted as proper patches to John, and will hopefully go in soon). The differences are:
Comment #9
Steven CreditAttribution: Steven commentedjQuery 1.0 alpha, modified.
Comment #10
Heine CreditAttribution: Heine commentedA few minor IE related issues with the latest patch, all about the fancy front of the patch. As an aside; quick animations do make collapsible fieldsets more natural to use.
Fieldsets - collapsed fieldsets lost the line around the legend, except for the very beginning and end.
File attachments - a very jarring transition of the 'Attach new file' title on the the file attachments fieldset when uploading.
Autocomplete - On node submission forms, upon choosing an autocomplete entry with enter an error 'beep' sounds unless the attach button has been used before and receives focus. It is not possible to continue typing in the autocomplete textfield (it just lost focus). The list of entries doesn't fade out.
Comment #11
kkaefer CreditAttribution: kkaefer commentedUpdated the patch against HEAD. No further changes.
Comment #12
Morbus IffSubscribing.
Comment #13
Bèr Kessels CreditAttribution: Bèr Kessels commentedanother subsciption
Comment #14
eaton CreditAttribution: eaton commentedTesting against a clean head. Collapsing fieldsets, resizable textareas, autocompletion of the username field, and file uploads are all working very nicely. Is there any ETA on jQuery 1.0?
Comment #15
webchickthis is a patch
Comment #16
rkerr CreditAttribution: rkerr commentedThis will be great to get in :)
Comment #17
notabenem CreditAttribution: notabenem commentedsubscription as well.
what I read so far is ... impressive to say at least.
Comment #18
yched CreditAttribution: yched commentedEr... subscription...
Comment #19
rickvug CreditAttribution: rickvug commentedSubscription. Been playing with jQuery on a 4.7 site and I must say it's impressive.
Comment #20
Steven CreditAttribution: Steven commentedNew patch which namespaces all the Drupal stuff under a global Drupal object to reduce the chance of conflicts with other libraries.
Comment #21
Dries CreditAttribution: Dries commentedDo we know more about the state of jquery, and whether they'll relicense? ETA?
Comment #22
kkaefer CreditAttribution: kkaefer commentedFor some reason, the patch breaks collapsible fieldsets at the moment.
Comment #23
Dave Cohen CreditAttribution: Dave Cohen commentedI find that simply adding the latest jquery.js breaks collapsible fieldsets. That is, rather than applying any patch, I simply drupal_add_js('path/to/jquery.js').
Would love to know how to fix it.
Comment #24
eaton CreditAttribution: eaton commentedI believe the solution is to apply this patch. :-)
Comment #25
Dave Cohen CreditAttribution: Dave Cohen commentedWhich patch exactly do you mean?
My javascript skills are weak, but I believe it has to do with jquery.js adding its own onload event. And its behavior somehow interferes with drupal's onload chain of functions. In my case, where I include jquery.js before any other js that calls addLoadEvent, simply changing the order of load events worked for me. That is, I changed addLoadEvent to read:
instead of the other way around.
I don't expect this to necessarily work for all installations.
Comment #26
Dave Cohen CreditAttribution: Dave Cohen commentedI think I see what you mean by "apply this patch" now. I did not think that would solve the problem because of timcn's comment #22. (haven't applied it yet as I'm afraid to break the site).
Comment #27
eaton CreditAttribution: eaton commentedyogadex, when I use the patched copy of jquery in #9 with the drupal patch in #20, things work fine on my end. Collapsing fieldsets, file uploading, etc etc.
Comment #28
kkaefer CreditAttribution: kkaefer commentedCollapsible fieldsets only break with the latest patch and latest SVN-jQuery because they changed $.set() to $.attr(). You just have to change that in one single place and it works fine again.
Comment #29
scroogie CreditAttribution: scroogie commentedThere is some information regarding that in the group ajax-developers at http://groups.drupal.org/ajax-developers
The developer of jQuery (john resig) is active there. I dont know how much you already read about it, so here are some small quotes:
the 1.0 alpha has already been released:
http://jquery.com/blog/2006/06/30/jquery-10-alpha-release/
Comment #30
radev CreditAttribution: radev commentedSubscribing.
Comment #31
eferraiuolo CreditAttribution: eferraiuolo commentedinterested and subscribing also
Comment #32
forngren CreditAttribution: forngren commentedSubscribe
Comment #33
recidive CreditAttribution: recidive commentedIs jQuery definitely going to be on Drupal core?
In general the patch is working fine (tested with jQuery 1.0 alpha), I've updated the patch to sync with lastest changes in common.inc and theme.inc.
I have some thoughts/questions regarding the proposed patch:
Class based javascript
With this magic function:
We can write JavaScript "classes" this way:
Instead of doing repeated code like
object.prototype.method = function()
.Simple Object inheritance
Another helpful approach in Prototype is the ability to easy extend an javascript object/class though the Object.extend method:
with this approach, the setOptions method for the Drupal.Collapsible class above will look like this:
Does jQuery have a similar approach for doing things like these?
Observer design pattern example
Giving javascript a class based aspect, we can make use of several useful OO programming design patterns. With the "observer" design pattern we can monitor a widget and easy extends its functionality. E.g.:
Give our Drupal.Collapsible class an aggregation object (Based on scriptaculous' Draggables)
Add to methods collapse and uncollapse of the Drupal.Collapsible class
How to use this from other applications
Creating a Collapsible Observer
Adding the observer to our application
In general, as you might see, this looks like the Drupal hooks mechanism, so why not adding this kind of flexibility in javascript too?
With jQuery being core drupal will be quickly gaining nice Ajax functionality. However I don't like to see this thing holding us from doing drupal.js enhancements before the next codefreeze.
Comment #34
scroogie CreditAttribution: scroogie commentedThe discussion about prototype and other ajax toolkits has been made in the ajax-developers group over at groups.drupal.org. The link is in my post above.
Comment #35
anders.fajerson CreditAttribution: anders.fajerson commentedSubscribing (...and missing rss feeds for comments)
Comment #36
kkaefer CreditAttribution: kkaefer commented@recidive: jQuery also has something like that: jQuery.extend().
Comment #37
Rok Žlender CreditAttribution: Rok Žlender commentedSubscribing
Comment #38
kkaefer CreditAttribution: kkaefer commentedUpdated the patch to reflect the JavaScript streamlining patch now being in core, the removal of
drupal.css
and recent changes in the SVN version of jQuery.This does only work with a recent version of jQuery, the files directly on http://jquery.com are outdated. Get a recent version either via SVN or here. For development purposes, take the big file with all the comments in there. The final file that will be included with Drupal is the small one (15kB).
I also noticed that the fieldset collapsing is broken in Safari. The first time, you open a fieldset, nothing show up. When you close it again and reopen it, everything works fine.
Comment #39
kkaefer CreditAttribution: kkaefer commentedReworked the
textarea.js
. Its done from 3709 bytes (pre-jQuery) over 3422 bytes (jQuery before) to 957 bytes (now). I tested it in Firefox, Safari and Internet Explorer 6 and 7. I'd like to get some other reports, too.Comment #40
recidive CreditAttribution: recidive commentedNice work, Konstantin!
I tested the textarea in two other browsers:
Konqueror: broken (the old behavior seems to be disabled in this browser);
Epiphany: working.
Also, your patch is breaking the collapsible fieldset arrow in system.css (line 245):
background: url(../../menu-expanded.png) 5px 75% no-repeat;
The right path is
../../misc/menu-expanded.png
.Are you going to refactor other widgets?
What about extending the collapsible.js to blocks?
Why not writing Drupal widgets as jQuery plugins?
How could we customize the widgets behaviors, e.g. change default effects, change behavior selectors from a theme, etc?
Comment #41
m3avrck CreditAttribution: m3avrck commentedSubscribing, will help test and debug later today / tmorrow.
Comment #42
m3avrck CreditAttribution: m3avrck commentedNo longer applies :-/
The ideas about JQuery plugins make sense--JQuery is a lot like Drupal, it has tons of great plugins and lots of people working on those, all GPLed. Maybe we can reuse stuff. Will require research since those seem to be spread out all over the net.
Comment #43
kkaefer CreditAttribution: kkaefer commentedNew patch, now with jQuery included.
Comment #44
eaton CreditAttribution: eaton commentedFor plugin management, I think we'd do well to offer a central module that manages them, and allows other modules to say, "I need plugin X to do my thing." Drop in plugins, and they become available to other modules. That would prevent us from running into situations where modules drag along numerous differently versioned jQuery plugins and start colliding.
That's a post-jQuery-in-core issue though, I think.
Comment #45
Crell CreditAttribution: Crell commentedJohn Ressig (jQuery author) has said that one of his plans for post-1.0 of jQuery is to build a contrib repository on the jquery site rather than plugins being scattered all over the web. Hopefully he'll have the same license requirements that Drupal does (in his case, MIT/GPL dual licensed like jQuery itself), which will be great for us.
I'm not sure how we want to handle contribs, but is there some way we could integrate or tie into that?
Comment #46
Steven CreditAttribution: Steven commentedErr, in textarea.js, all the carefully tweaked measuring and adjustments for the grippie have just been stripped out? There was a reason for all that stuff...
Comment #47
kkaefer CreditAttribution: kkaefer commentedWell, we could add it back in again, but I tested the textarea grippie in several browsers and could not find one where it was necessary. I have tested with Safari, Firefox and Internet Explorer 6 and 7.
Comment #48
Steven CreditAttribution: Steven commentedHmmm kay... we'll see whether we get any comments about the textarea stuff.
Here's an updated patch, tested with jquery SVN. Most stuff seems to work, but it needs some more looking over and testing.
Comment #49
Steven CreditAttribution: Steven commentedjQuery 1.0 is out and I have a tested patch sitting here. Works fine in Firefox, Safari and Opera. Needs some IE looking over.
I did have problems getting the compressed version of jQuery to work, but the uncompressed one works fine. Perhaps there are still some last minute problems with the code packer. But you can test it using:
http://jquery.com/src/jquery-1.0.js (put in
misc/jquery.js
)Comment #50
kkaefer CreditAttribution: kkaefer commentedWhy did you revert the jsEnabled changes? jsEnabled does not need to be a function.
Comment #51
gollyg CreditAttribution: gollyg commentedsub
Comment #52
dvessel CreditAttribution: dvessel commentedMust be a better way to subscribe.
Comment #53
m3avrck CreditAttribution: m3avrck commentedI've put up a dev site so we can test JQuery in multiple browsers:
http://dev.tedserbinski.com
I tested in IE6 and all seems to work good. Only thing that is off is the resize, it doesn't line up correctly... otherwise no problems.
Comment #54
kkaefer CreditAttribution: kkaefer commentedDamn, I thought nobody would see that ;) I'm fine with reverting the textarea.js back to what it was before, getting jQuery in and slowly rewriting it after feature freeze or for the next version.
And the fieldset collapsing does now work smoothly on Safari :)
Comment #55
yched CreditAttribution: yched commentedOn http://dev.tedserbinski.com/ :
Editing node/1, adding an attached file and submitting the form crashes my Firefox (1.5, WinXP)
Sometimes I don't even need to submit, I crash during / just after the upload
Comment #56
m3avrck CreditAttribution: m3avrck commentedHmm, no problems with FF 1.5 on a Mac
Comment #57
eaton CreditAttribution: eaton commentedI just went through a couple edit rounds, uploaded files, submitted, etc on FF 1.5.6 Windows XP. no problems.
Comment #58
yched CreditAttribution: yched commentedI just tested again, and I crashed again - Well, maybe this is caused by one of my firefox extensions...
Other thing : the "author" autocomplete field in the node edit form doesn't seem to work
Comment #59
eaton CreditAttribution: eaton commentedAutocomplete, too, is working fine for me on FF 1.5.6 WinXP. Can you try firing up Firefox in 'safe mode', sans extensions, and see if the problem persists?
Comment #60
yched CreditAttribution: yched commentedWith FF in safe mode :
- OK for file attachment. Are you interested in me digging through my extensions to find the offending one ?
- still no autocompletion for me. The widget just does not seem to react to key press (except it inserts the char, of course...)
someting else :-) :
To test for the autocompletion, I typed a dummy (non existent) author name.
Then I forgot about it and submitted the form.
The validation failed as it should, with the correct error message and the "author" field outlined, but the fieldset below (publishing options) had become "inactive" (plain text, no link to fold / unfold)
See attached screenshot.
Comment #61
Anonymous (not verified) CreditAttribution: Anonymous commentedthis fixes 2 things...
1) autocomplete.js - if there are no results, it will now not show the popup and fadeout with no content
2) collapse.js - fixes fieldset collapse after validation (steven fixed this)
Comment #62
pwolanin CreditAttribution: pwolanin commentedIs there any way to avoid the delay when expanding/collapsing the fieldsets? I find this highly annoying compared to the immediate expansion in 4.7.
Comment #63
webchick@pwolanin: I think that effect on the fieldsets is something Ted maybe has done to his test site for illustrative effect... applying this patch to a clean HEAD for me causes them to expand/contract the same as in 4.7.
No problems here in FF 1.5 for Mac. Tested fieldsets, autocomplete, updater, and file uploads.
Will try and dig up some more "obscure" browsers to test with...
Comment #64
Steven CreditAttribution: Steven commentedWe already use 'medium' speed, so you could change that to 'fast' in collapse.js. But I find the animation makes it easier to see what moves where, especially with the smooth scrolling during the animation. The old 'snap' wasn't friendly in that aspect.
Comment #65
webchickOh, nevermind. Apparently the old behaviour was cached, so pwolanin is right.
-1 for the slow-speed expansions. :P Everything else you click happens instantaneously, so it's inconsistent. It also seems like added fluff "just because we can." But I guess as long as I can change it with a hook_form_alter or something... mutter, grumble... ;)
Comment #66
Dries CreditAttribution: Dries commented- I like the animation and I think it's a subtle usability improvement, but it could do being a tad faster. I agree with the others that it is too slow. Normally I go 'click-click', now I have to go 'click-wait-click'.
- I like the fact that the page automatically scrolls as you open a fieldset near the bottom of the page. However, it has to scroll a little bit further: the bottom borders of the collapsible fieldsets are still outside the screen. As a result, you can't be sure that the entire fieldset is visible, and the user still has to scroll. That is, it has to scroll an extra 25 pixels or so.
- If you open the last fieldset on the node edit page, the 'Preview' and 'Submit' button scroll of the page. That's annoying because I'll have to do extra scrolling to get the buttons back. So maybe, we should always scroll an extra 50 pixels or so to avoid that extra scroll. (The fact that the 'Publishing options' is the last fieldset makes this particularly annoying. I need these settings a _lot_.)
- The autocomplete functionality (usernames on the add node form) aren't working for me either. I'm using Firefox on the Mac.
Comment #67
Jaza CreditAttribution: Jaza commentedThe test site is working very nicely for me. Great work, Ted and co!
A few issues, while testing on WinXP, with FF 1.5.0.6, IE 6.0, and Opera 9.0:
Comment #68
Anonymous (not verified) CreditAttribution: Anonymous commentedwith the animation lengths, instead of using 'medium' or 'fast' .. we should use a number. we can have it like slideUp(600); and that may be better.. some of you try and manually adjust the effects and see what numbers you can come up with.
regarding the fieldsets not scrolling down enough to show everything.. a good idea would be to make it scroll the offsetHeight of the field set + an additional bit.. this could solve that problem.
Dries: not sure why the autocomplete on user names is not working for you on firefox mac. that's exactly what im on and everything is working.. hmm...
I'm going to roll another patch today.
Comment #69
Steven CreditAttribution: Steven commentedActually it does scroll further than it needs to, but I used Safari to decide the fudge factor. It seems firefox adds more space inside the fieldset, which causes it to be not enough.
I'll look into getting the positions right again, for the grippie and fieldset.
Comment #70
Anonymous (not verified) CreditAttribution: Anonymous commentedok try this..
this changes the speed to 400. it is a lot faster.
this also changes so the collapseScrollIntoView(node) uses node.offsetHeight to better align the screen with the fieldset and show the entire fieldset.
Comment #71
Anonymous (not verified) CreditAttribution: Anonymous commentedthe scrolling on fieldsets, its a bit jumpy because of the amount of distance it needs to go and its just the native scrollTo() function which does not have an animation.
I think I'll write us a custom ScrollTo() function just like in the Interface plugin for jQuery so it atleast slides up nicely.
another thing, the speed at 400 for the slide up / slide down effects.. on my version i changed it to 200 now and its even better.
Roll another patch later with hopefully the ScrollTo() function.
Comment #72
m3avrck CreditAttribution: m3avrck commentedUpdated dev site: http://dev.tedserbinski.com
Comment #73
webchickCategories fieldset is buggy here: http://dev.tedserbinski.com/?q=node/2/edit.
Firefox 1.5, Mac.
It starts expanded. When I click on the fieldset it "unexpands" as intended. When I click on it to expand it again though, it jumps the whole screen down so you can no longer see the "categories" fieldset, just the "test:".
Comment #74
eaton CreditAttribution: eaton commentedwith firefox 1.5.0.6 on winXP, the grippie is misaligned a bit. screenshot attched.
Also, when a fieldset expands, it seems to scroll to the very bottom of the page no matter which one I open.
Comment #75
kkaefer CreditAttribution: kkaefer commentedAs I said before, let's revert back to the old
textarea.js
to solve the aligning issue. Once we have it in core (hopefully before Sept 1), we can refactor these functions.Comment #76
Rok Žlender CreditAttribution: Rok Žlender commentedSth weird happened to me when testing on http://dev.tedserbinski.com/ I tried to add a page and in category field "Test" I typed sth and then pressed backspace until the text was gone and a few times more very fast. The result is in my screenshot. This doesnt happen on any other field not even on another autocomplete field.
Another maybe related thing. How to reproduce:
1. type in sth into "Test" category field delete the text and wait ( the clock is still turning even if there is nothing written)
2. now try to type in "Authored by" field in my case autocomplete feature is not working
This are some errors that I get:
IE
Line: 633
Char: 10
Error: 'getAttribute' is null or not an object
Code: 0
URL: http://dev.tedserbinski.com/?q=node/add/story
Firefox
Error: elem has no properties
Source File: http://dev.tedserbinski.com/misc/jquery.js
Line: 632
Error: this.style has no properties
Source File: http://dev.tedserbinski.com/misc/jquery.js
Line: 1004
I tested this on windows version of FF 1.5.0.6 and IE 6
Comment #77
Dries CreditAttribution: Dries commentedWith the latest patch, the scrolling is really bumpy (to the point that it is a regression rather than an improvement).
Comment #78
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commentedI tried to apply the latest patch from Steven Wittens against my fresh HEAD checkout and with one offset it applies cleanly to my install..
But unfortunatly I could not get any JS-related thing to work. All fieldsets are closed by default, and nomatter what I do, they keept closed. Clicking on it doesn't reveal anything..
I was suspecting the fact that my localhost failed to add jQuery or something, but everything seems to be in the right place.
All JS-files are there and doesn't contain any parse errors or whatever..
It's pretty strange imo..
Will checkout and review this once there is a new patch available..
Comment #79
Bèr Kessels CreditAttribution: Bèr Kessels commentedNot sure if we should really bother, but i'd like to report this anyway: Trying the http://dev.tedserbinski.com/?q=node/add/story example in konqueror 3.5.2. makes the uncollapsing behave really weird and un-user-friendly.
The uncollapsing effect is very bumpy (stop-motion effect). (collapsing is fine)
The worst however, is that my window scrolls to the point where the fieldset of the uncollapsed item, sits at the top.
If I am editing the title, then decide to click on the "File attachements" field label, my window scrolls up (putting the title field I was just editing out of the viewport) and the "File attachements" field tries to scroll to the top. If there is a not lot of content, it will scroll up only a few lines, but with lots of content below that field (uncollapse all fields to see this effect at its worst), I am totally lost for a few seconds. After all: All I did was open a fieldset, not scroll up and down, suddenly i see a whole different screen (it seems).
Bèr
Comment #80
edmund.kwok CreditAttribution: edmund.kwok commentedSame here, applied the patch to new HEAD checkout but the fieldset were not clickable. Using Firefox 1.5 on Mac.
Comment #81
Owen Barton CreditAttribution: Owen Barton commentedFor those that haven't noticed jQuery 1.0 is out: http://jquery.com/
In the meantime the code freeze is tomorrow! Most of the problems described above seem to be with the fieldgroup dropdowns (either it not working, or a general dislike for this functionality). Since this functionality could (as far as I see) easily be added by a few lines of code in a contrib module it seems like it is hardly worth holding up the issue for.
I would like to propose we drop this subfeature from the patch, update the code to jQuery 1.0 and concentrate on getting this into core as soon as we can!
I would have a go at fixing this patch up myself - but I have a suspicion that Steven probably has been working on this since the last patch he posted. Any updates?
Comment #82
Steven CreditAttribution: Steven commentedOkay, I tested and tweaked this patch and it's pretty much ready to go into core.
The only serious issue that I saw in this patch was an error box in Opera when uploading a file for the first time. I couldn't pinpoint the cause of this in the JS code itself, so I'm pretty sure it's a browser bug. I'll get in touch with Opera QA for this, but
The jQuery version I used is jQuery 1.0.1 compressed.
So, I went ahead and committed it to HEAD. jQuery is an essential part of the 4.8 API, and the bugs that are there now and only in the core widgets' usage it. We'll resolve them as they pop up.
Comment #83
(not verified) CreditAttribution: commentedComment #84
GiorgosKI tested http://dev.tedserbinski.com/ with IE5.0 on win98 (default browser)
and I get some scripting errors.
Jquery supports IE5.5 and up
Even the site http://jquery.com gives some javascript errors
Should we be using something like this
(I could not find something specific to IE5 in the jquery site)
Comment #85
GiorgosK(sorry code was stripped from drupal formatter, here it is)