Re: HTML_QuickForm and improved version of advmultselect component

On Wednesday 01 June 2005 10:22 pm, Justin Patrin wrote: > On 6/1/05, Ian Eure <ieure@php.net> wrote: > > On Wednesday 01 June 2005 05:30 pm, Justin Patrin wrote: > > > On 6/1/05, Laurent Laville <pear@laurent-laville.org> wrote: > > > > Hi all, > > >> > > >> (snip) > > >> > > > > I could then start a proposal if nobody is against this idea. > > > > > > I'd like to mention for everyone's benefit that this isn't a normal > > > multi-select, it's two select boxes next to each other emulating a > > > multi-select. > > > > Thank you for that clarification. > > > > My concern is the same as the last time this came up; I think it needs to > > be backwards-compatible with non-JS browsers. > > "needs" is a strong word. Yes, allowing non-JS browsers to use > elements is good but this is a *very* small percentage of browsers. > Unfortunately JS got some bad press in the past (mostly due to > insecure implementations) but JS is a *good* thing. It should be > turned on and it should be used. > I fully agree that JS is a good thing, I just think it's bad practice to leave people who don't have it in the lurch. It would be an entirely different matter if there was no equivalent in plain HTML, but this is clearly an enhancement of the existing control. > However, that said, I allowing non-JS browsers to work is a decent idea. > > > The way to accomplish this is: > > > > - Send a regular multiple select control in the markup, with a class set > > so you can identify it later. > > - Use JavaScript to: > > = Change the name of the original control to something else > > = Create the second select element, giving it the correct name (the > > "old" name of the element in the markup > > = Create any necessary controls, buttons, etc. > > = You'll also need a handler to set the "selected" attribute of > > everything in the 2nd select element when the submit button is clicked. > > This is good in theory, but how do you handle customization, such as > custom layout? It could be a big pain to get this implemented well. > Do you have a specific case in mind where CSS wouldn't work for this? > > Since the scripted element is functionally identical to the normal > > multiple-select, it seems like a bad idea to make it incompatible with > > older browsers. > > > > I'd be glad to work on the JS end of things if help is needed. > > Sure, if you can get it working that would be great. > Ok. Laurent, do you have a code drop or CVS I can work from? The jalessio.com links give me 404s. > > I also created a "script" element for QF a while back, for just this type > > of embedded-scripting scenario, but my changes were rejected. If it's > > possible, I'd like to propose that as a QF subpackage, since I think it's > > useful, particularly in this scenario. I have no idea if there's > > something different I have to do to create/propose a subpackage, so > > input/suggestions on this point is welcomed. > > I never actually looked at this element... Proposing a subpackage is > the same as proposing a package. Just get it set up and propose it. > Is this (http://synapticmedia.net/~davey/PEAR/pear-core/docs/rfc01_PEAR_subpackages.txt) document still relevant, or is there a new way of doing subpackage dependencies?

Attachment: [application/pgp-signature]