Re: [drupal-devel] Docking Boxes.
I would like some more peoples ideas on this. Should we consider to include this API in drupal for our javascript needs, rather then creating our own?
Oh, absolutely. I have included JavaScript menus in several Drupal sites I have constructed. Since Drupal prefers not to have JavaScript (AFAIK), maybe just inot include it with core, or if it is included, have it disabled by default? Kobus
Oh, absolutely. I have included JavaScript menus in several Drupal sites I have constructed. Since Drupal prefers not to have JavaScript (AFAIK), maybe just inot include it with core, or if it is included, have it disabled by default?
We love JavaScript as long as a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it. Autocomplete fields (nice job, Thox) are a prime example. However, his implementation still have problems with a). And most likely, every implementation will have problems there. The reason for not having JS in Drupal yet is the job required for true cross-browser JS. Regards NK
Op maandag 16 mei 2005 10:24, schreef Karoly Negyesi:
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it. d) it is efficient code (http://home.earthlink.net/~kendrasg/info/js_opt/) e) it does not open security holes f) it is safe enough not to -ever- crash a browser.
ad f) the fill out stuff, as used on php.net, and by the google test labs, is knwh to crash khtml, and thus konqueror and safari. IMO crashing is even worse than "not working". Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bèr,
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it.
d) it is efficient code (http://home.earthlink.net/~kendrasg/info/js_opt/) e) it does not open security holes f) it is safe enough not to -ever- crash a browser.
ad f) the fill out stuff, as used on php.net, and by the google test labs, is knwh to crash khtml, and thus konqueror and safari. IMO crashing is even worse than "not working".
Also add to the list 'does not impair using the web site if disabled', since accessibility requires that front-ends and back-ends (hence the administrative portion) work nicely without Javascript, to allow users with disabilities complete use of the site's functions even if they use helpers, screen-readers, do not use a keyboard / mouse, etc. For example, the recent (2004) italian Accessibility Act requires all public offices to only adopt CMS which comply with the above (obviously, among other requirements partly derived from the USA Section 508 and from the WAI WCAG). - -- Andrea Resmini vector@exea.it -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCiOgrEHn5bB6bDvERAq0yAKDZf2dDh2CQVVIKfaPFCfKMFRtaiwCg0Qen hzNDHI8sGN1+T/FQwi0JUJU= =tSAY -----END PGP SIGNATURE-----
A couple thoughts. +1 for not rolling our own JS library. It would be counterproductive and there is already good work being done (SAJAX, prototype.js and Dojo, my personal favorite simply because I know the main developer). Drupal should focus on the backend stuff and integrate with someone else's JS layer where possible. +1 for accessibiIity. I wholly agree with Andrea that whatever we provide needs to be accessible. This is a core value of the Dojo project and I already have some ideas for "accessifying" the latest Docking Box example. Anyway, this is a good discussion and I wonder if anyone has opinions about the various JS libraries that are out there, since now you know my bias. Chris On 5/16/05, Andrea Resmini <vector@exea.it> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bèr,
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it.
d) it is efficient code (http://home.earthlink.net/~kendrasg/info/js_opt/) e) it does not open security holes f) it is safe enough not to -ever- crash a browser.
ad f) the fill out stuff, as used on php.net, and by the google test labs, is knwh to crash khtml, and thus konqueror and safari. IMO crashing is even worse than "not working".
Also add to the list 'does not impair using the web site if disabled', since accessibility requires that front-ends and back-ends (hence the administrative portion) work nicely without Javascript, to allow users with disabilities complete use of the site's functions even if they use helpers, screen-readers, do not use a keyboard / mouse, etc. For example, the recent (2004) italian Accessibility Act requires all public offices to only adopt CMS which comply with the above (obviously, among other requirements partly derived from the USA Section 508 and from the WAI WCAG).
- --
Andrea Resmini vector@exea.it -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCiOgrEHn5bB6bDvERAq0yAKDZf2dDh2CQVVIKfaPFCfKMFRtaiwCg0Qen hzNDHI8sGN1+T/FQwi0JUJU= =tSAY -----END PGP SIGNATURE-----
Hi Op maandag 16 mei 2005 20:36, schreef Andrea Resmini:
b) Degrades nicely.
Also add to the list 'does not impair using the web site if disabled', since accessibility requires that front-ends and back-ends (hence the administrative portion) work nicely without Javascript, to allow users with disabilities complete use of the site's functions even if they use helpers, screen-readers, do not use a keyboard / mouse, etc. For example, the recent (2004) italian Accessibility Act requires all public offices to only adopt CMS which comply with the above (obviously, among other requirements partly derived from the USA Section 508 and from the WAI WCAG).
option b) is the short version of your long story. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bèr,
b) Degrades nicely. option b) is the short version of your long story.
Well, yes and no. What I wanted to point out is that, in some cases, working without Javascript is becoming more and more a requirement of the Law, in connection to accessibility. Not complying with this is going to seriously impact the possible legal use of Drupal in public web sites in the next years, at least in Europe where this is the line at the EU IT commission, so 'degrades nicely' is maybe a bit milder than it should be. That's all. - -- Andrea Resmini vector@exea.it -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCiP5wEHn5bB6bDvERAi/VAKCd4k2culz9/3VJ4hT+9u+ekqhGugCfUANI zcNbWdFsAIhAkLkYu21hUR4= =pT8S -----END PGP SIGNATURE-----
On Mon, 16 May 2005, Karoly Negyesi wrote:
Oh, absolutely. I have included JavaScript menus in several Drupal sites I have constructed. Since Drupal prefers not to have JavaScript (AFAIK), maybe just inot include it with core, or if it is included, have it disabled by default?
We love JavaScript as long as
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it.
The order should be c), b), a). I addition, we should decide on a set of browsers which we want to support and simply give the non JS version to all others. Cheers, Gerhard
Gerhard Killesreiter wrote:
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it. The order should be c), b), a). I addition, we should decide on a set of browsers which we want to support and simply give the non JS version to all others.
I think for core it needs to be $a && $b && $c; Anything else is not good enough. If there is going to be fudging on this - let it be done in a distro of Drupal and not in core - at least until its $a && $b && $c. andre
On Mon, 16 May 2005, Andre Molnar wrote:
Gerhard Killesreiter wrote:
a) Works with all browsers. (At least IE6, Opera, Firefox, Safari, Konqueror) b) Degrades nicely. c) There is real gain from using it. The order should be c), b), a). I addition, we should decide on a set of browsers which we want to support and simply give the non JS version to all others.
I think for core it needs to be $a && $b && $c; Anything else is not good enough. If there is going to be fudging on this - let it be done in a distro of Drupal and not in core - at least until its $a && $b && $c.
Well, iff a) should be difficult (I _really_ have no idea about if it could be, I am no JS expert) for one of the less often used browsers (Opera, Safari, Konqueror) we should decide to not support it in core and prefer to hava a clean API and clean JS without too many hacks to achieve compatibility for any of those lesser used browsers. We should have an API for contrib modules to provide JS for such browsers. Personally, I'd be happy to not include support for IE in core as well if it should be difficult to support. Cheers, Gerhard
participants (7)
-
Andre Molnar -
Andrea Resmini -
Bèr Kessels -
Chris Messina -
Gerhard Killesreiter -
Karoly Negyesi -
Kobus Myburgh