Template talk:Skill progression

Alignment

This table looks really strange centered, when all the content we have is either right or left aligned. Can we have this left aligned? It makes it easier to read under the skill description and looks a lot less awkward. - BeXoR 23:59, 1 April 2007 (EDT)

Bexor - you're pretty much the wiki style guru. If you think it looks better then you should go for it, you're probably right. :D I was just copying from what was around before. --Aspectacle 00:31, 2 April 2007 (EDT)

Well I'll change it and when everyone has a cry they can do so here. - BeXoR 00:37, 2 April 2007 (EDT)

*cry* - Anja Astor 02:06, 2 April 2007 (EDT)

Oh no! It takes a bit of getting used to - it makes the page look very left handed if you've got a big monitor. --Aspectacle 02:08, 2 April 2007 (EDT)

Yea, on my screen (in my eyes maybe) it looks really odd. Before it was a nice balance with the right aligned skill box. - Anja Astor 02:10, 2 April 2007 (EDT)

I think it looks good to the left. LordBiro 06:09, 2 April 2007 (EDT)

Anyone thinks it should at least have a little cell padding? -- ab.er.rant 05:02, 4 April 2007 (EDT)

Not personally. LordBiro 05:04, 4 April 2007 (EDT)

It already does have cellpadding. Any more and it will look bloated. - BeXoR 06:08, 4 April 2007 (EDT)

Maximum

I've created {{Skill progression limit}} which determines what the length of the row should be based on the attribute. At the moment it is only used if maximum is not specified. Since I was unsure whether the attribute parameter would be a link or not, I have switched based on the unlinked attribute.

I don't really think the attribute should be linked, since the attribute will already be linked in the skill infobox, but I have brought this up at Guild Wars Wiki talk:Formatting/Skills#Maximum attribute levels. LordBiro 06:35, 5 April 2007 (EDT)

You might want to remove the changed parameters from usage too. - BeXoR 00:14, 6 April 2007 (EDT)

Ok! LordBiro 07:02, 6 April 2007 (EDT)

Micro-font part II

As per the discussion I was mistakenly having at User talk:LordBiro/Skill box draft 5#Micro-font, why are we using such a small font for the progression table? The old tables at GW make much better use of available space - I'm not suggesting we copy them, but I don't understand how presenting the numbers with such a small typeface improves things. --NieA7 10:49, 5 April 2007 (EDT)

Repetitive data doesn't need to be in full font size (i.e. things that you've read once and don't need to again, like headings or such), but seeing as the progression table data is unique to each page, I can see why the full font size would be required. - BeXoR 11:30, 5 April 2007 (EDT)

I'm in favor of a full size too. It's hard to read even for me with perfect sight. (when wearing my glasses ;) ) -- (gem / talk) 11:33, 5 April 2007 (EDT)

I just got new glasses! 90% has always been easy for me to read though, as long as I have them on. I can see about 20cm without them. - BeXoR 11:39, 5 April 2007 (EDT)

It is readable if you concentrate on it, but I don't want to need to use more time and concentration to see how much the skill wil benefit me when I'm scrolling through skills and builds. It does make a big difference in time that I need to use on a skill page, I've tested. -- (gem / talk) 11:47, 5 April 2007 (EDT)

It should be changed - of course. I was expecting to get pulled up on this much sooner

(and probably with a bit more indignation) because this discussion has already taken place. :P It was cheeky of me to implement it with the small font knowing full well that there was a large discussion and concensus for the default font size further up the skill formatting page. Forgive me for using this template to make a small point about how the format is easy to change once the template parameters are finalised.

With this in mind I've immediately removed the font size 90% parameter. , but you might like to consider increasing the cell padding from '2' to '3'. --Aspectacle 13:08, 5 April 2007 (EDT)

I've also changed the cell padding from 2 to 3. It makes the progression less of a great blob of numbers that way. --Aspectacle 13:15, 5 April 2007 (EDT)

Much better now. I totally forgot that it was allready agreed on the skill formatting page. -- (gem / talk) 13:56, 5 April 2007 (EDT)

I put the cellpadding back to 2, I thought 3 was a bit too much... I hope you don't mind! I also reduced the size of the header, although I'm not sure if that was a good idea, lol. LordBiro 14:27, 5 April 2007 (EDT)

I changed my mind, sorry, 3 does look better!! LordBiro 14:34, 5 April 2007 (EDT)

It's rare to see you change your mind, but it's good to see it atleast once in a while so now we know that it is possible. ;P -- (gem / talk) 14:45, 5 April 2007 (EDT)

Hehe, well I don't like doing something until my mind is made up, but that was an unusual spur of the moment change ;) LordBiro 17:05, 5 April 2007 (EDT)

Template Change

Why not try to change the color of the background on the template, for example (Warrior):

Progression
{{{attribute}}}	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21

Using the colors from: List_of_elite_skills_by_campaign Note: its possible adding the ranger, ritualist, assassin, dervish, paragon, monk, mesmer, necromancer... colors. the template page can be uopdated with those "template example" already with the new profession colors.

We use the green color to make it consistent with the skill infobox :) - Anja (talk) 06:48, 2 May 2007 (EDT)

Of course but by adding diferent skill progression templates, it would save a lot of work Template:w_skill_progression <- this for example, alos if we change this the skill box also needs the same changing (in the colors perspective (warriors template skillbox... etc), it gives a lot of work but in the end it worth it (sorry for my poor english)

What work do you mean it saves? I don't see anything else than more work with your suggestion, since all skill articles would have to be changed, for example. Plus, I think the consensus was to use the same infobox for ALL skills, and thus have the same color also. It makes the articles easier to recognise, imo :) - Anja (talk) 07:01, 2 May 2007 (EDT)

If you see User:BeXoR/Infoboxes you can see the way colours represent content. Using profession colours would just confuse things more. The skill infobox has the nice big profession image in the background, as well as the profession name and icon in the details, so it's not difficult to recognise which profession the skill is for. - BeX 07:19, 2 May 2007 (EDT)

I didnt know about those, still like the prof color based templates tho. but it its defined that way, theres anything i can do in this matter. --The preceding unsigned comment was added by User:194.210.96.137 .

It was a general consensus, but isn't official yet. If you feel like convincing everyone to change it, then I suggest you do so here Guild Wars Wiki talk:Formatting/Infoboxes. There have been several discussions about it already though, scattered around the wiki, so I don't know how successful that would be. I personally much prefer the current system and think it makes more sense in the broader spectrum of wiki articles. - BeX 08:03, 2 May 2007 (EDT)

Move to CSS

I would like to suggest a move to CSS-classes for the table elements:

{| class="skill-progression" cellpadding="3" cellspacing="0" rules="all"
|- class="skill-progression-header"
! colspan="23" | Progression
|- class="skill-progression-1strow" 
{{Skill progression line | {{{attribute}}} | 0 | 15 | {{skill progression limit| {{{attribute|}}} }} }}
|- class="skill-progression-row" 
{{#if: {{{var1 name|}}} | {{Skill progression line | {{{var1 name}}} | {{{var1 at0}}} | {{{var1 at15}}} | {{skill progression limit| {{{attribute|}}} }}  }} }}
|- class="skill-progression-row" 
{{#if: {{{var2 name|}}} | {{Skill progression line | {{{var2 name}}} | {{{var2 at0}}} | {{{var2 at15}}} | {{skill progression limit| {{{attribute|}}} }}  }} }}
|- class="skill-progression-row" 
{{#if: {{{var3 name|}}} | {{Skill progression line | {{{var3 name}}} | {{{var3 at0}}} | {{{var3 at15}}} | {{skill progression limit| {{{attribute|}}} }}  }} }}
|- class="skill-progression-row" 
{{#if: {{{var4 name|}}} | {{Skill progression line | {{{var4 name}}} | {{{var4 at0}}} | {{{var4 at15}}} | {{skill progression limit| {{{attribute|}}} }}  }} }}
|}

Any comments? See also Mediawiki_talk:Common.css. Any optimizations are welcome, I'm not the greatest CSS-artist. --  (CoRrRan / talk) 13:14, 7 May 2007 (EDT)

You don't need a lot of those classes. If the class of the table is "skill-progression" then you can set rules for the rows by saying .skill-progression tr { rule goes here }. The same applies to the header. For simplicity's sake it might make sense to keep the "skill-progression-1strow" class; you can apply rules based on the context, i.e. style all rows with a green background, but style all rows that follow a row with a white background, but IE6 doesn't handle these properly. LordBiro 14:53, 7 May 2007 (EDT)

I was wrong about th actually. The first cell in every {{skill progression line}} also uses a th, so a class is needed in order to differentiate between them.

I've put an example at User:LordBiro/Pain, and the CSS is in User:LordBiro/monobook.css. LordBiro 17:35, 7 May 2007 (EDT)

How come doesn't your example show the background colors? If you look at User:CoRrRan/Sandbox2, it does work as a normal {{skill progression}}-template. My CSS is located at User:CoRrRan/monobook.css and the updated template at User:CoRrRan/Sandbox. --  (CoRrRan / talk) 17:46, 7 May 2007 (EDT)

As I said above you don't need a lot of those classes, so my table in User:LordBiro/Pain is different to your version. Equally my CSS is shorter, because you don't need a lot of the CSS you've suggested. Have a look at my User:LordBiro/monobook.css. LordBiro 06:07, 8 May 2007 (EDT)

Oh wait! I didn't update my monobook.css stylesheet when I looked at your example. So I guess it's not showing correctly. --  (CoRrRan / talk) 07:28, 8 May 2007 (EDT)

Auto-wrap

Just implemented an auto-wrap method for this template. See also the discussions on Guild Wars Wiki talk:Formatting/Skills, on Infuse Health and on MediaWiki talk:Common.css. poke | talk 15:45, 18 August 2007 (UTC)

This now autowraps even for those who wasn't suffering from the display error, thus not needing it, meaning it looks rather horrible. Backsword 15:48, 18 August 2007 (UTC)

Do you have an example of one that didn't need it? On the ones I tested, it looks okay - although I would like to see some buffer space between the wrapped rows to improve readability. --- Barek (talk • contribs) - 15:49, 18 August 2007 (UTC)

It only wraps if you really need a wrap (=when there is not enough space for the table). And it is needed, see the discussion on Infuse Health. A buffer space is not possible without changing the layout for progressions where no wrap is needed and I don't think it would look better. Also this method is meant to make it possible that big progressions can be correctly displayed without floating into the Skill infobox. As this not happens for every users and for every page it should be not that big issue. poke | talk 15:57, 18 August 2007 (UTC)

Poke,

True, for me, my screen and resolution is big enough that I never saw the problem in the first place, only when I resized my window from full width. But, when it does wrap, the rows being close together does make it harder to read - at least to me a buffer space between them would improve that issue. I hate leaving a less-than-optimal display for even a sub-set of users, especially if the main argument for it is "not many poeople will see it displayed that way anyway".

Backsword,

You mentioned that the change was causing problems for a skill someplace, can you link to it? All the ones I've checked appear to only wrap if/when needed due to width restrictions. --- Barek (talk • contribs) - 16:04, 18 August 2007 (UTC)

When I made the template I tried different things to change the border etc. but everything looked stupid in some way when wrapped (for example all borders tied to the cells instead of the complete table or heading). A buffer space would be possible but then there would be always some whitespace - when wrapped and when not wrapped - but I simply think that it is not needed as the different rows has different background colors and you can easily differ them (imo). At the moment it is not possible to make a better wrapping without using complex javascript or something else. Because of this it is also not possible to repeat the variable titles for each row.

The reason I say "not many people will see it displayed that way anyway" is simply because it's true. The display resolutions today are normally 1024x768 or higher. The wrap problem only occurs on 1024x768 on progressions with 3 digit numbers. There are not that many skills that have 3 digit numbers so not many people will ever see this wrap. But because of the discussions there was a need to do something like this and I think it is ok. (Btw. I don't think we should change the view for the users who had a correct view so I do not think we should add a buffer space) poke | talk 16:13, 18 August 2007 (UTC)

Like I said, it looks okay ... I just think it could look better. To me, an argument that technical limitations prevent adding the buffer (as doing so would make it look worse when not wrapped) is a good argument - and I'm appeased by it. If the only argument was that not many would see it, that - to me - is a bad argument when used by itself.

But, as there is a technical limitation here, that's good enough for me. --- Barek (talk • contribs) - 16:24, 18 August 2007 (UTC)

I would like to hear more from Backsword.

As far as I can tell this change means that those articles that previously had problems now look better, and those articles that had no problems look pretty much the same. While an even better solution might exist (one with some 'buffer' perhaps) there is no doubt in my mind that this change was a good one. LordBiro 16:36, 18 August 2007 (UTC)

Just to clarify (as you're replying to me) at no time did I say this change was a bad one - I support this change. I only said that, if technically possible, I think readability could be better with a buffer between rows when wrapped. As it appears that this cannot be done without negatively impacting the appearance when not wrapped, I'm fine with it as-is, and support it as an improvement over how it was displaying. --- Barek (talk • contribs) - 17:37, 18 August 2007 (UTC)

I understand, Barek, I was just trying to make it clear to poke, more than yourself, that while there might be room for improvement his change is a positive one. :) LordBiro 18:11, 18 August 2007 (UTC)

Compare Image:User_Backsword_SPTnew.PNG with Image:User_Backsword_SPTold.PNG. These are from Golden Lotus Strike, but the same remains true for Infuse Health and several others. Only difference being the temp revert of this template.

(Delete pictures later, as they are screenshots) Backsword 19:45, 18 August 2007 (UTC)

First of all: don't change the template, to make a screenshot of an old version. Instead use the history, copy the code to your userspace and make it there, but changing the template will cause ~1000 skill pages to reset their cache! Second: Why are the screenshots that big? If you load the page and then make the font-size bigger (by CTRL + mouse wheel for example) it does not work, as the table loads it's own maximum size and then the content floats. Normally, it does not wrap (try reload and then just look) and it should work. poke | talk 23:14, 18 August 2007 (UTC)

I've tried those two skills under several different screen resolutions and window sizes - I can only get the table to wrap if/when it's too wide and should wrap. Because your screenshots only show the progression box and not the related skill box, it's impossible to tell from the screenshots if it is right up to the skill info box, but from my tests, being up to that box is the only time those two wrap, so I still fail to see the problem you've mentioned. --- Barek (talk • contribs) - 02:53, 19 August 2007 (UTC)

You can se the lower lef corener of the infobox in one of them. Basicly, it goes below the infobox, and is now wraped so it can be pushed up alongside it. From the debate over Infuse Health, it seems to be what most users get; the display problem seems to happen to some versions of firefox. Backsword 08:02, 21 August 2007 (UTC)

Again, it can only happen when you (after loading) change the font size.. Resizing window/resolution works if you reload the page. poke | talk 08:12, 21 August 2007 (UTC)

'fraid that's not correct Poke. I don't normally fiddle with such things, so it's not the case for my screenshots. Also, since you mentioned it, I went and tested it, and no, font size has an effect, but it is the same effect as screen resolution, irregardless of when fontsize is set. Backsword 08:40, 21 August 2007 (UTC)

But how do you set the fontsize? The screenshots show that that obviously is not the normal font-size. poke | talk 09:11, 21 August 2007 (UTC)

Wouldn't it be much simpler to add space between the top of the page an the progeression box? I use 1024X768 on IE7 and the progression box is wrapped because the skill info box is at the end of it. I get the same on firefox (at 1600X800) and Netscape (at 800X600 and 1024X768) and three different OS. By simply putting the progression box below where the infobox ends (or even above it) the full width of the page becomes available, and all but the lowest resolutions will not need wrap. Just my thoughts... Gwynna Vive 02:08, 5 September 2007 (UTC)

This would make more problems.. See Healing Hands for example: If the progression box is below the infobox there would be a very big useless and empty area. Also it is not guaranteed that the progression box is then fully displayed (for example with resoultions below 1024x786). poke | talk 05:27, 5 September 2007 (UTC)

This example displays fine on my machines, and I am not trying to get rid of the wrap, it is needed for low resolutions and will appear of every single progression regardless at 800X600 or lower. I do understand about the blank space as well. Perhaps adding the progression at the very top, and the infobox immediately below would work, or making the height scaleable so that long variable names (ie: domination magic) can be broken and still keep the table connected (top to bottom). Current design leaves the vertical lines short if the variable is 2 lines high. Again, just some thoughts and ideas. Gwynna Vive 02:47, 6 September 2007 (UTC)

Progression range

IMO we should use 0...20 for attributes without 20% +1 items and 0...21 for attributes with 20% +1 items. You can get any attribute up to 20 with Candy Corn, a Golden Egg, a Grail of Might and the appropriate blessing, monsters can have attributes as high as 20 in Hard Mode and attribute raising buffs can't bring an attribute above 20. -- Gordon Ecker (talk) 04:24, 24 November 2008 (UTC)

Yes, the current ones seem fairly random. Rather than wild guesses at what people may use, just list a few more values and be sure, since we now know the max. Backsword 20:50, 30 November 2008 (UTC)

I've implemented it now. Backsword 19:17, 16 December 2008 (UTC)

Simplifying and extending this template.

A long time ago, there was talk about a problem with this template: it didn't work on small screen resolutions. This lead to the talk two sections above this and finally a a workaround. However, this solution had several drawbacks:

• It doesn't use a proper table, but divs that are meant to fake a table.
• It's impossible to copy/paste into spreadsheets, since it's not a table.
• While it fixes some problems, sometimes browsers choke on it and display weird stuff, even when there's enough screen estate. (see also the discussion above)
• The code is a mess and virtually impossible to extend.

So, all these problems to work around a browser bug from 2007? My current firefox can display it just fine. It will either move the progression below the infobox, or add a scroll bar below the screen.

Error from 2007: , screenshot from today:

Also, unlike 5 years ago, monitors with <1024px horizontal resolution are very uncommon. The whole bug is a non-issue these days, and IMHO not worth the costs of the workaround.

Hence I propose getting rid of the workaround and changing the template back to the simplified version. This will allow us to maintain the template in the future, making it simpler yet more powerful and extensible.

I've started doing so here:

User:Tub/Sandbox/Skill progression / User:Tub/Sandbox/Skill progression row

These two templates are meant to replace:

{{Skill progression}} / {{Skill progression line}}

In addition, the new version incorporates the functionality of:

• {{Skill progression factored}}
• {{Skill progression limit}}
• {{Skill progression max6}} (actually not needed)
• {{Skill progression max10}} (for skills linked to Sunspear / EotN titles)
• {{Skill progression max10WW}} (not sure why it was ever created)
• {{Skill progression max12}} (for skills linked to Luxon/Kurzick titles)

It also supports lightbringer rank now, because even those two (or three?) skills deserve love.

Long story short: Objections, opinions? Tub 01:21, 20 February 2012 (UTC)

Perhaps the template should also have parameters that can be used to manually enter the progression figures for Spirit Siphon's energy gain, Wastrel's Demise's maximum damage, Rising Bile's maximum damage, and Signet of Illusions. --Silver Edge 21:47, 20 February 2012 (UTC)

Yes, that's one of the things I had in mind when talking about making it "extensible". Working it into the current template would be a major pain, but adding it to the new one is kinda easy, I just haven't found the time to add it between all the GW2-videos that popped up and stole my time. ;)

If you know more examples than the five skills you mentioned, please let me know about them so I can add testcases for every one of them. Tub 23:49, 20 February 2012 (UTC)

Yes, please. – Tennessee Ernie Ford (TEF) 00:05, 21 February 2012 (UTC)

The Attuned Was Songkai and Auspicious Incantation pages. --Silver Edge 05:48, 21 February 2012 (UTC)

I've added testcases for all except Attuned Was Songkai, because cost tables use a different layout. Also added lightbringer skills.

As far as I'm concerned, everything I wanted to do with the template has been done. Let's wait a while for further feedback.

You may have noticed that the table borders are black instead of dark green. Changing this will require a change in MediaWiki:Common.css, so I'll have to find an admin to assist me with the migration when the time comes. Volunteers? Tub 12:24, 21 February 2012 (UTC)

Okay, let met try to give you some insight on what was the problem back then - I hope I remember everything correctly.

The original code was a table just like you are proposing now (it's not really good to see if you are introducing anything else, markup-wise, so if you do, please tell me; it might be good to provide a pure mark-up example for comparison too). The problem was indeed on lower resolutions where the page and skill infobox didn't leave enough room for the full progression table to be displayed. The problem appeared in two steps, which are replicated again in your solution: When shrinking the page, first, the table tries to save up as much as horizontal space as possible to keep it in place. This has the annoying effect that it will introduce line breaks and mess up spacing. If you shrink even further, then the table gives up, and jumps below the infobox which introduces a lot whitespace. Especially back then, when there were no concise descriptions, this was even worse; but it's still a problem in my opinion.

My solution basically tries to avoid this by overflowing as soon as possible without messing up any spacing, or introducing empty vertical whitespace. I agree that it is a very hacky and complicated solution, which makes it far from being perfect, but it does its job rather well, and still seems to work exactly as expected in all browsers.

I wouldn't be too happy to see this going back to the original code, even for the sake of code clarity (btw. due to the logic, I don't think your code is cleaner either ^^). While possible width might not be such a big problem on desktop computers, it definitely is an issue for all (semi-)mobile devices which I am definitely thinking of targetting somewhere in the future. And as it is, the current progression templates scales perfectly on those low resolution devices. poke | talk 22:09, 22 February 2012 (UTC)

Thanks for the review. Yes, it's just a table, as it was back then. I was under the impression that the initial issue was the browser bug from the screenshot above, but I see that you're concerned about it looking pretty on low resolutions, too.

The first problem, where it adds linebreaks to shrink the table, can be solved with a simple "white-space: nowrap;". I meant to add that but somehow forget.. it's there now! Tested and works on FF and IE, no more table mangling.

The second problem has three possible solutions:

1. Accept the empty space when the whole table gets pushed below the infobox.
2. Accept that only parts of the table are visible at a time, and add a scrollbar. Attributes >16 are rarely interesting, anyway.
3. Accept breaking UI consistency, by using your div-hack.

The first two solutions can now be seen in my sandboxed template. Both work as expected in IE and firefox (save for some unwanted spacing between table and scrollbar, but that's fixable).

So I do like having correct values on Spirit Siphon et al, I do like having a template that can be extended without writing a code-generator, and I do like being able to select or copy/paste the table without problems. While I appreciate your concern for mobile devices, I'd place my priorities on correct values and usability for the major case, and wouldn't sacrifice either for the increasingly uncommon case of low screen resolutions. But our opinions may differ on that.

That said, I've shown that we can prevent the introduction of unwanted line breaks on low resolutions, and I've shown two table layouts that work on low resolutions. At that point, I think it boils down to personal taste which of the three layouts is preferable and would call all three of them acceptable, though neither is perfect. I don't really care if it's 1) or 2), I just wish to avoid the one that's difficult to code and breaks UI consistency. Would you call 1) or 2) acceptable? Tub 00:05, 23 February 2012 (UTC)

I have little to add to this discussion other than to say that keeping things usable and aesthetically pleasing for mobile devices and other smaller screensize should not be just dismissed without thought, which is what you seem to be doing Tub. Statistically speaking, the numbers of users on smaller devices is climbing at a higher rate than those using widescreen monitors. A lot of gamers use their computer to play, and their phones, or tablets to view the wiki at the same time. As far as I can see what you call poke's "div-hack" seems to be doing the job, and unless there have been some major changes to the way skills progress through the game, I'm not sure I see a valid reason to change it. I'm not a big fan of scrollbars, they are an inconvenience, and even more so on mobile devices. -- Wyn talk 05:24, 9 March 2012 (UTC)

I'm not forgetting those, I just disagree that a minority of users should be the determining force behind any changes. I'd place the priorities like this:

1. Correct values. The current template doesn't do that for some skills with derived values.
2. Ease of use for the majority of our readers. A hack that breaks the layout in subtle and not-so-subtle ways and completely breaks copy/pasting does not fit that description. See 1, 2, 3, 4, 5, 6, 7, 8 for some examples with broken layouts for all our users, and don't forget the discussion above this one which highlights further problems.
3. Ease of use for the editors. A hoard of different templates for different corner cases that still don't cover all the cases doesn't fit that description. Some skill articles have resorted to hardcoded tables, which says a lot.
4. Ease of use for the minority of our readers, i.e. users on phones and lowend-tablets. In this case the hack was an improvement over the template from 2005 (which completely broke on low resolutions), but is only a minor improvement (if any) over my two suggestions, which work fine but require scrolling when there's not enough room. The hack merely trades horizontal scrolling for vertical scrolling; whether or not that's an improvement is a matter of taste.

There's no solution that satisfies *all* points in *all* cases - I don't see one, and none has been suggested. Any change will be a tradeoff. My template greatly improves points 1-3, at the cost that about a dozen skills will have either an additional scrollbar or some empty space for <1% of our readers. No broken layouts, just some scrolling, which is just a finger-swipe on phones and tablets. I'm convinced that that's a tradeoff worth making. Tub 12:47, 9 March 2012 (UTC)

I recently started using my phone to read the wiki and I still support Tub's order of priorities. There might not have been a major change in the way that skills progress, but there are changes in the way we document skill utility. Accordingly, previously excellent and/or fit-for-purpose templates on this wiki need to evolve to meet the needs of our audience and our editors. – Tennessee Ernie Ford (TEF) 17:48, 13 March 2012 (UTC)

Manual values when formula-induced progression is inaccurate

Judging the section above, there was never a solution found for variables that do not follow the progression formula. Notable examples are Spirit Siphon and the energy gain via regeneration for Energetic Was Lee Sa. I made a test template in my sandbox that allows manual input for such values. See here.
My wikifu isn't amazing, but it appears to function. Can anyone with stronger coding skills take a look and perhaps edit/create a version for use on the mainspace? - Infinite - talk 22:28, 12 July 2017 (UTC)

Does my template work across all browsers? (Up-to-date link: [1].) I can only test for Firefox and Chrome, personally. If it does work, I can update the main template. - Infinite - talk 09:49, 26 October 2017 (UTC)

Tested in IE, Chrome & FF and that template works fine with manual values. ShadowRunner 10:19, 26 October 2017 (UTC)