> This is what I have done in past. > http://mootools.net/shell/UZ4TF/
Hey, you're going to have some collisions with that workaround (like 'ab' and 'a b' are both tamed to 'ab')! :) Something that is two-way like URL-encoding would be a better approach. Also should use HTML data-* as the attribute name so this would potentially validate. But, back to the OP, I have to suggest there is a less-than-best practice underlying this problem, even if there is also a bug in Moo. IME, the `value` attribute on option elements is usually a "magic string" that should be replaced by a numeric index. Most of the time, the value is initially (or should be) drawn from a database or at least a separate array either on client or server. There's no situation I can think of when both option values and text must *only* be defined in the markup. Just because the corresponding value is known at the time the option is drawn doesn't mean you need to write it all directly into the document. When you use numerics for your possible values, a great advantage is server-side validation. Just cast to an int and make sure it's within the known length of the array and nothing unwanted can sneak in. You don't need to escape any strings nor re-match them to the allowed picklist. A second advantage is bandwidth: you don't have to pass any "friendly names" back across the wire on the form post. Third, I think, is clarity: a distinct client- or server-side array is much easier to read than picking data out of the markup, and as noted, once you have an array, why would you also copy it wholly into the markup? I'm not saying it isn't convenient and sometimes necessary to copy the values inline, but I think that is a practice that deserves some scrutiny. -- Sandy
