I guess I understand the syntax part of the question, but what I don't understand is why in some cases a METAL declaration is needed. Let me give you an example, a code snippet from a stock Plone site. This code is inside a <metal:block define-macro>:
<tal:block tal:condition="no_types">
<select id="filter_selection" name="filter_by_portal_type:list" style="float: left" onChange="submitFilterAction()" tabindex="" tal:attributes="tabindex tabindex/next|nothing;">
<option value="#" tal:attributes="selected python:test((len(filterTypes)>1 or len(filterTypes)==0), 'selected', '');" i18n:translate="label_show_all_items"> Show All Items </option>
<metal:block tal:repeat="type types"> <option value="#" tal:define="typetitle type/Title; typeid type/getId" i18n:translate="label_show_x_only" tal:attributes="value typeid; selected python:test( len(filterTypes)==1 and (typeid in filterTypes), 'selected', '');" ><span i18n:name="type"><span i18n:translate="" tal:content="string:${typetitle}" tal:omit-tag="" /></span>s only</option> </metal:block>
</select>
<input type="hidden" name="filter_by_Subject:tokens" value="" /> <!--you can filter by subject keywords by filling in this value-->
</tal:block>
You mean the option repeat toward the end, right? I can see why that would be confusing. There really isn't any reason (apart, perhaps, from historical) for that to be a metal:block. If it needs to be a block, it would be better written as '<tal:block repeat="type types">'. Of course, that tal:repeat could/should probably be moved into the option tag, which is what is really repeating. (Though perhaps the use of the define nixes that. I'd have to check the order of operations.) Similarly, the very first tag has redundant information, and could be written '<tal:block condition="no_types">'. Note the extract above works just fine (although perhaps a little slower than it might otherwise be) because of the way namespaces work. Saying <metal:block> gets you nothing more than the ability to use metal attributes without their own namespaces in a non-rendering tag, and unless you actually use a metal statement in it, it's essentially equivalent to, say, <span tal:omit-tag="">, but shorter and less explicit. (Plus a little extra compiler work, I guess.) And, as the first tag points out, there's no problem with explicitly specifying the namespaces even when they're implied. It's just a little more typing. --jcc