Template talk:Head

From TheKolWiki
Jump to: navigation, search

AHA! Now, we can unlock that familiar template. Since we can now create section headers in templates without (as many) worries...still testing.--Dehstil (t|c) 23:22, 20 June 2006 (CDT)

After further testing, it doesn't seem as nice.--Dehstil (t|c) 23:43, 20 June 2006 (CDT)

There it works well now.--Dehstil (t|c) 15:48, 23 June 2006 (CDT)


I kinda like this and hate it at the same time. I like what it attempts to do, but I don't like how the style is hardcoded within. If a change it ever made in the css regarding h2s, this would have to be updated. These also do not show up in TOCs, because they are not real headers. This just seems very... what's the word I'm looking for... kludgy? --JRSiebz (|§|) 21:19, 23 June 2006 (CDT)

Yeah, inside it's ugly, but to the user, browser and even the wiki parser, it's somewhat pretty/transparent. As for styling, mag would have to code a .sectionheader class into the css for this template can hook into it. To be included into the TOC the parser counts the h2, h3 etc tags and uses those for the table. Unfortunately, it automatically assumes these tags were generated by itself and thus each have a section. In actuality, there are only as many sections as there are ==Sections==. So the parser numbers theses h tags from 1 to whatever for the edit links. If we attempt to manually add h tags they break the page's edit by section functionality, so any attempt to let these headers be toc'ed would break any page using them. So, the next best thing is a identically styled div tag. If mag, messes with the skin anytime soon, tell him to add .sectionheader to the style block used by h2.--Dehstil (t|c) 22:00, 23 June 2006 (CDT)

Not Functioning/Explained Properly

It seems this template isn't working precisely as intended (and/or needs its proper use better clarified), especially the "anchor" parameter. An anchoring issue came up with the Established Standards: Item Pages page, and I've traced the issue to the use of {{head}}. You can see that page's talk page for further details on attempts to resolve/find the issue. A typical example of what was being used on that page was {{head|anchor=no|Uses}}, however an anchor was still being produced. It was still produced if I moved the anchor field to the end of the code. At least for those of us using the Opera browser (like myself, but not Bagatelle, who was not having this issue). Removing all attempts at using the anchor parameter has fixed the problem for me. Furthermore, the "Fake Anchor" example on the page is actually anchored. And what is the "Clockwork Grapefruit" parameter in the last example supposed to be doing? Creating an auxiliary anchor? It's not doing that, if so. It's not changing the text shown on the page, either. --Flargen 00:06, 4 February 2008 (CST)

  • Fixed. That was an easy fix, now that I know how the parsing templates work. And I figured out what the other parameters are doing. Though we should probably put more explicity instructions/documentation in for that. --Flargen 02:29, 30 December 2008 (UTC)