ayg wrote:

What makes this superior to just putting the template at the top? That's where
people will expect to find it in the wikitext anyway; people will get confused
if they try to change the infobox and the code is actually at the bottom of the
page.

thomas.holden wrote:

Well often there are multiple templates that always go together, one element of
which goes at the top and another element of which goes at the bottom, so one of
the principal merits is just in saving editing time / making it harder to forget
to add the second half = a more uniform style within a category = a good thing.

Also it would make it a lot harder to make layout errors. For example, when
adding navigation boxes / stub templates / etc. to the bottom, you want to put
the template text after the last real text, but before the category links and
the interwiki links (this seems to be the convention anyway). However when
you're trying to be quick, lists of see also links look a lot like lists of
category links, so it's quite easy to end up sticking your box in the middle of
the article. Even if you're not as dozy as me and you do always put it in the
place you intended, it's still often quite hard to find, trapped between two
sets of links towards the bottom (and this is assuming everyone's following the
same location convention, it could be anywhere in the interwiki and category links).

With my system almost all templates could be clearly placed at the top of the
file, where they are easily findable, and do not get in the way of the main
article body. Of course this is just another convention that people could choose
to ignore, but to me at least it seems like it has a lot greater chance of being
followed. Plus if you really wanted to you could enforce the convention quite
easily with my system. E.g. if a template only contains text in <header> and/or
<noinclude> then put it at the top of the file.

I'm not sure how convincingly I'm presenting this case, I just know from my own
experience that I could have saved myself a lot of time (or refactored more
pages) if we had this system, both in adding templates, and in finding the
template I needed.

Maybe I'm crazy/too lazy/odd.

Sample: An article in the KSH WP about year looks approx. like this:

{{Navvi_Joohr_Kopp|||1|9|3|3|...}}

Em '''Joohr 1933''' ...
....

{{Navvi_Joohr_Fooß|||1|9|3|3|...}}

Parameter lists are identical. It could be replaced by:

Em {{Joohr|||1|9|3|3|...}} ...

....

2/3 less chances for mistakes, souce more readable, 550,000 keystrokes saved for the
4500~5000 Year-Articles to have, that is 76.4 hour of labour for an experienced average
user. On this sample issue alone.

How would you separe on which levels should be done?

If {{Template1}} is "a <header>b</header> {{template2}} <footer>c</footer>"
And {{Template2}} is "<footer>d</footer> e <header>f</header>"

What output is the correct one?

• a b d e f c (a not affected, header b closed by footer c)
• b a d e f c (a affected, header b closed by footer c)
• b a f e d c (each template orders by itself)
• b f a e d c (headers and footers are absolute)
• b f a e d c (footers on parent blocks have priority)
• b a e c (only one header & footer per page)

thomas.holden wrote:

Interesting point, I'm not sure it's a problem though, as long as you understand
that if multiple header blocks are found, they are all placed in the header, and
the order is given by th e order of the blocks. Likewise if multiple footers are
found, the first footer goes to the bottom, the second to the second from bottom
etc. Thus in this particular case the correct options is:

b f a e c d

(b f a e d c might also make sense, but I like the idea that the outermost
header and footer tags will always "get their own way".)

I can't imagine this case would occur too often though, and when it does occur,
normally the order of the headers and footers wouldn't matter too much.

Tom

How about leaving the choice to the editor, where these:

<footer add="before"> ... </footer>
<header add="behind"> ... </header>

are the defaults, and those:

<header add="before"> ... </header>
<footer add="behind"> ... </footer>

could as be specified?

One might even think of an extension that allows local handling inside a <div> ... </div> bracket:

<header add="before-in-div"> ... </header>
<footer add="behind-in-div"> ... </footer>

Purodha

Another esthetically nice application could be to put special content *behind* all lists
in category pages.
See this one: http://ksh.wikipedia.org/wiki/Saachjropp:Bier

Is this still relevant/do we care?

Yeah, it's not solved.

I'm not sure I like this idea. It breaks out of the expected bounds of the template system and doesn't seem to have a balance in favour of the idea.

Most of the header / footer template use cases I see IMHO should in fact be handled using a new type of extension to add things, like nav to the header and footer.

In the current example given we don't even need a special extension. Practically all of the information being inserted into said template is actually within the title and follows a near strict pattern.
In other words a simple basic header and footer powered by lua taking no parameters could handle their entire use case. And if we felt like it a simple extension could even automatically prepend/append the template output to the pages following said pattern.