and in template:
href="<!-- TMPL_VAR NAME="url" -->"
Paul's point is the same as I would like to make: using this method removes the option for the template designer to use a form instead of a link. What about leaving both options open? Have the script create the URL variable but also make all the individual variables available for use?
<!-- TMPL_LOOP NAME="items" --> <option value="<!-- TMPL_VAR NAME="value" -->" <!-- TMPL_VAR NAME="selected" -->><!-- TMPL_VAR NAME="name" --></option> <!-- /TMPL_LOOP -->
Paul, is this method translator-safe? I thought you had had difficulties in the past with constructions like this? In both cases, past practices have colored my attitude towards these practices: Any time the script generates HTML, you run the risk of no complying with the standard chosen by the template designer. This was a problem when we were transitioning between HTML and XHTML. If we can all agree on complying with XHTML transitional (at least), we just need to follow the rules: URLs which are generated by the script must include proper encoding of ampersands (& instead of &) "selected" attributes generated by the script must follow the rules of no implied attributes: selected="selected" So it comes down to three suggestions from me: 1. Make options available to the template designers. 2. Ensure that generated markup is XHTML compliant 3. Find out if we're breaking the translator script :) -- Owen