Short description
The popular JavaScript library JQuery should be included in all page headers (MoinMoin/theme/init.py) so MoinMoin extensions and themes can make use of it.
Advantages of JQuery
it's easy to program "eye candy" for your pages and plugins with it.
- small code size (~19kByte minified and GZipped)
- extendable by plugins
- cross browser, your code will run in all major browsers
- well documented
- there are a lot of demos and plugins available. Have a look on this pages and enjoy like I did:
Accessability
We should for sure also discuss accessability. How do we ensure, that disabled users can navigate through feature rich sites also?
- we could make guidelines for how an extension must be programmed and testet to ensure accessability.
extensions which fullfill accessability criterias could get some kind of "MoinMoin accessability certificate". So each one can see, that he can use a nice looking theme or plugin but also people are able by some kind of switch to enable an accessability mode. This "MoinMoin accessability certificate" could be marked with a nice logo on the MoinMoin markets.
A MoinMoin extension fully stuffed with "eye candy" (for example a dynamic menu or a slide show for pictures, ...) must provide a special mode for high accessability also. If not they don't get the "MoinMoin accessibility certificate".
Discussion
- Wow, you can really do great stuff with jQuery. Thanks for pointing that out!
Some
of these features also could be done by CSS. Concerning accessibility, it simply needs to be assured that a wikipage (and its functionalities like e.g. image editing) could be used by keyboard only and not only by mouse. So using "onmouseover"-event to dynamically display edit-links is surely not accessible. There is no way for people navigating a page with the keyboard("tab-key") only, to activate this link. Even when doing such things by using "onfocus"-events, things become very complicated. Since beginning of 2009 we have for this the W3C WAI ARIA guidelines. To get the on-focus stuff work e.g. for screenreader user, you have to use new attributes in the image like aria-owns="Pop-Up-Link" so as to connect the stuff popping up (by jQuery/Javascript) with the image and you have to use aria-live="assertive"> in the div/href to notify the blind user about an important chance in the page. However ARIA is cutting edge in accessibility and is only supported by the latest assistive technology. And assistive technology is expensive. You cannot expect people to have always the latest software. So why do it in a difficult way if there is also a much easier way? In the case of image editing this means: simply put an icon/button bar underneath a picture which could be easily reached by keyboard/old assistive technology and could be hidden in print.css and projection.css.
Related topics
FeatureRequests/NewImageEditors, especially the discussion there how to invoke the image editor by e.g. adding dynamically a link with jQuery when one hovers over an image with the mouse or by clicking on a red dot in the image.
For the inaccessibility of image maps (concerning the red dot solution), see ParserMarket/ImageMap/ReleaseNotes.