MediaWiki talk:Common.css/Archive1

From Guild Wars Wiki
Jump to navigationJump to search

This page is an archive. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Discussion on this page is not current. Any additions you make will probably not be read. The current version of this page can be found at MediaWiki_talk:Common.css.

/*

Requests

Hiding specific columns in tables

Supports hidecol1 ~ hidecol10. Also need MediaWiki talk:Common.js#Request for Internet Explorer compatibility. 

*/
table.hidecol1 th {display:none;}
table.hidecol1 th + th {display:table-cell;}
table.hidecol1 td {display:none;}
table.hidecol1 td + td {display:table-cell;}

table.hidecol2 th + th {display:none;}
table.hidecol2 th + th + th {display:table-cell;}
table.hidecol2 td + td {display:none;}
table.hidecol2 td + td + td {display:table-cell;}

table.hidecol3 th + th + th {display:none;}
table.hidecol3 th + th + th + th {display:table-cell;}
table.hidecol3 td + td + td {display:none;}
table.hidecol3 td + td + td + td {display:table-cell;}

table.hidecol4 th + th + th + th {display:none;}
table.hidecol4 th + th + th + th + th {display:table-cell;}
table.hidecol4 td + td + td + td {display:none;}
table.hidecol4 td + td + td + td + td {display:table-cell;}

table.hidecol5 th + th + th + th + th {display:none;}
table.hidecol5 th + th + th + th + th + th {display:table-cell;}
table.hidecol5 td + td + td + td + td {display:none;}
table.hidecol5 td + td + td + td + td + td {display:table-cell;}

table.hidecol6 th + th + th + th + th + th {display:none;}
table.hidecol6 th + th + th + th + th + th + th {display:table-cell;}
table.hidecol6 td + td + td + td + td + td {display:none;}
table.hidecol6 td + td + td + td + td + td + td {display:table-cell;}

table.hidecol7 th + th + th + th + th + th + th {display:none;}
table.hidecol7 th + th + th + th + th + th + th + th {display:table-cell;}
table.hidecol7 td + td + td + td + td + td + td {display:none;}
table.hidecol7 td + td + td + td + td + td + td + td {display:table-cell;}

table.hidecol8 th + th + th + th + th + th + th + th {display:none;}
table.hidecol8 th + th + th + th + th + th + th + th + th {display:table-cell;}
table.hidecol8 td + td + td + td + td + td + td + td {display:none;}
table.hidecol8 td + td + td + td + td + td + td + td + td {display:table-cell;}

table.hidecol9 th + th + th + th + th + th + th + th + th {display:none;}
table.hidecol9 th + th + th + th + th + th + th + th + th + th {display:table-cell;}
table.hidecol9 td + td + td + td + td + td + td + td + td {display:none;}
table.hidecol9 td + td + td + td + td + td + td + td + td + td {display:table-cell;}

table.hidecol10 th + th + th + th + th + th + th + th + th + th {display:none;}
table.hidecol10 th + th + th + th + th + th + th + th + th + th + th {display:table-cell;}
table.hidecol10 td + td + td + td + td + td + td + td + td + td {display:none;}
table.hidecol10 td + td + td + td + td + td + td + td + td + td + td {display:table-cell;}

/*

TOC display level limiter

<div class=toci>__TOC__</div> will only displays up to level i
*/
.toc1 li.toclevel-6, .toc1 li.toclevel-5, .toc1 li.toclevel-4, .toc1 li.toclevel-3, .toc1 li.toclevel-2 {display:none}
.toc2 li.toclevel-6, .toc2 li.toclevel-5, .toc2 li.toclevel-4, .toc2 li.toclevel-3 {display:none}
.toc3 li.toclevel-6, .toc3 li.toclevel-5, .toc3 li.toclevel-4 {display:none}
.toc4 li.toclevel-6, .toc4 li.toclevel-5 {display:none}
.toc5 li.toclevel-6 {display:none}
/*
  • /

Discussion

I know you've been doing this on GuildWiki, but I don't really see the benefit of being able to hide specific columns. And while being able to limit the TOC level is nice, shouldn't this be up to the user? I don't think it's our place to override the default behaviour of the TOC. LordBiro 12:10, 16 April 2007 (EDT)
I see simple column hiding via class as the next evolutional step from creating customized qr templates for different needs. It's easier for a generic user to go "I want to hide columns 3 and 8 of my own copy of that big table, so I'll declare class='hidecol3 hidecol8'", as opposed to looking at an existing qr template, figure out what all the template formatting coding means, and come up with their own template (or identify and approach a power user to ask for help). Baby evolutional steps to make things simpler.
Fine, and I'll admit that I really don't like the idea of creating a new qr template for every potential combination of criteria (same damage type, same requirement, no prefix; different damage time same requirement, no inherent bonus; etc etc). Column-hiding is, in my opinion, a more elegant solution on an exponential level than creating individual templates for each combination of columns I would want to hide. Nor do I feel like going through the trouble plugging each row of the existing max stat weapons (every unique, collector, and weaponsmith weapon) into their own templates like what we did with skills on GuildWiki (I think the skills have a better utilitarian argument for using that approach, while the balance of pro/cons for applying the trick to weapons differ).
As for TOC level... *shrug*, it affects the TOC in a similar fashion that Template:TOCright does, in the sense that its existence does not directly influence anything. The default behavior of the TOC is not overridden here, this just provides the tools so if somebody wants to specify the TOC behavior on certain pages, the tools exist to do so. The lack of tools never prevented us (people on GuildWiki) from hacking an "fake" TOC that didn't even have the collapse function real TOCs have, so it was kinda "broken". The TOC limiter would've been a much better solution (although that "functionally-broken" hack never generated anywhere near the amount of controversy that TOCright has). For the TOC level limiter, I'd be willing to go with whatever policy we have for TOCright (though there didn't seem to be a consensus). If I don't have the TOC limiter, then for articles I want to limit the levels of TOC displayed, I'd simply __NOTOC__ the page and run that old hack (maybe implement the show/hide feature via javascript too, but I know there would be people who would not like that even if it's just to emulate part of the default TOC behavior). Those are my reasoning, I'm probably not going to fight hard for them here, but just want to explain my side of the view and kinda answer your question. -PanSola 06:39, 17 April 2007 (EDT)
Bump. LirdBiro, are you implicitly encouraging me to implement ugly workaround hacks via usages of obscure templates? -User:PanSola (talk to the File:Follower of Lyssa.png) 07:03, 5 May 2007 (EDT)
Perhaps I'm being slow, but I don't see the application for this kind of thing. Are you suggesting that instead of having multiple templates for quick references that we instead use one quick reference template and hide the columns that aren't relevant? That idea doesn't seem particularly elegant to me. CSS is useful for styling what the user sees, but the content sent via XHTML should be correct. We don't know that the user has CSS switched on, and if the user uses a screen reader it's debatable whether they would see the styled or the unstyled content. Not to mention that we'll be increasing the content sent to the user significantly. If this isn't what you meant then could you produce an example?
I should also mention that we're almost certainly not using that system for producing quick references.
When it comes to the TOC, I don't like TOCright, but I'm in the minority and I accept that. So I'm not as fussed about the toc limiter. LordBiro 07:57, 5 May 2007 (EDT)
Actually, I was thinking instead of having quick references templates at all, we should just have data as data and not use templates at all (unless it's for common table headers). Example: Mesmer perfect weapons (where you'll see the unstyled content unless you are using the proposed CSS modifications). I am thinking that, unlike how we handled skill data on GuildWiki, we will not put weapon data into individual templates. If I want to create a "Reduce blindness weapons quick reference", or "20/20 weapons quick reference" (one article for all attributes), I'll manually copy the entire row of relevant weapons, and past them into a new table. For this reason, each row must follow the same format, regardless of which columns the table want to display (in a table of Mesmer weapons only, it is unnecessary to display the per-weapon information that it deals chaos damage, if at the top of the page it is already mentioned). For someone who doesn't have CSS switched on, the downside is he will be seeing the unnecessarily redundant data (like the "Chaos damage" for mesmer weapons). The upside is it makes creating specific weapon quick references very easy because all weapons will be following the exact same format. The experimental part is that instead of dumping each weapon's data into a template, we keep it in raw wiki code and just copy-paste them. For certain reasons, I really don't feel like dumping each and every collector and crafter weapon into its own template to be called by quick references (although that seem to be the only non-CSS alternative). The template system has its merits with respect to skills, but with weapons it's just messier, so I currently favor the CSS approach. -User:PanSola (talk to the File:Follower of Lyssa.png) 10:25, 5 May 2007 (EDT)
That system doesn't really appeal to me.
I'll use the skill articles as examples here, simply because this is the area I am most familiar with, but I believe the same will apply to other areas such as armor and weapons.
The advantage to the system used on GuildWiki is that data in quick references is pulled from the same location as the data in skill articles, so there is no redundancy. The disadvantage is that it's difficult to edit skills, because the information is in a separate template. It's also fairly unintuitive.
Your suggestion doesn't have the advantages of the GuildWiki system, since you would have to copy and paste code, and if a skill was altered in an update you would have to manually edit each quick reference it occurred in. I also don't think it's considerably easier to edit; I certainly don't thin the advantages of your suggestions necessarily outweigh the disadvantages of the GuildWiki method.
An ideal system would be one where there is no redundant data and where articles are no more difficult to maintain than at present. I believe that DynamicPageList meets this criteria, since it allows us to automatically produce quick references, i.e. there is no need to write out a list of skills, it automatically produces a table of skills that cause a deep wound, for example.
I have expressed reservations towards DPL, but I think it is a better solution than the CSS one. LordBiro 11:57, 5 May 2007 (EDT)
Well, when it comes to skills, I also think the GuildWiki system is better. However, with weapons, I think we can safely agree that the probability of a change in certain weapon stats is extremely nil, so there's hardly ever a need to manually edit each QR a weapon occured in following an update. There's hardly a need to deal with maintainence of existing data. I think there have been approximately only 4 updates total, since the game's release, where existing items' stats have been altered.
In comparison, the chances of new weapons being introduced without a new campaign (as has happened with the SF update and the Lotus Staff update), or the need to create new weapon QRs, is much greater. In this scenario, the score of whether you follow the GuildWiki system or my proposed system is:
  1. each QR will need to be manually edited to add the relevant weapon (for both systems). Tie.
  2. for new weapons, the weapon stats would need to be entered once (for both systems). Tie.
  3. for QRs listing weapons whose stats have been entered once, my system requires a simple copy-paste of an entire row. The GiildWiki system probably requires a copy paste of "{{:Kristoffir Roi/Lotus Staff (Divine Favor)}}" (since most collectors offer TWO different Lotus Staves), or perhaps "{{:Lotus Staff/Kristoffir Roi/Divine Favor}}" or some other ordering. It all comes down to copy-pasting, so Tie.
  4. It is gonna be significantly easier for someone to add a row for a newly added weapon under my proposed system. Creating the articles "[[Kristoffir Roi/Lotus Staff (Divine Favor)]]" et al is harder. One point for PanSola (though this is offset by the fact that expert contributors can easily add the info, so one can argue we don't need to care about novice contributors' problems with adding new information).
I also support the use of DPL for skill quick references. However, I consider the circumstances of the weapon quick references to be different, and preferences for it may need to be evaluated. -User:PanSola (talk to the File:Follower of Lyssa.png) 12:42, 5 May 2007 (EDT)
Edit conflict :(
I didn't say that the GuildWiki system was better, it's just different. I did not suggest the GuildWiki system be used under any circumstances. I don't even think it should be used for skills on GuildWiki, so it goes without saying that I don't think it should be used for weapons on this wiki. I don't like the GuildWiki system, and I've said so a lot. I was only using that system as a reference. Here are some further opinions on this proposal:
  1. using irrelevant content in the (X)HTML and using CSS to hide it will have mixed results for screen readers or those with accessibility problems. This system effectively breaks semantics. One point against your system
  2. if there are N quick references then we will probably need to have an extra N columns for each weapon, to contain the unique information for that quick reference. This means the user will download the size of the visible page + the size of each column * N (approx.) since they will download columns only for them to be hidden by the CSS. One point against your system
  3. since many quick references will contain identical (X)HTML it will be impossible for search engines or other programs that parse (X)HTML to tell the difference between the majority of the content. One point against your system
I'm sorry PanSola but I've not been persuaded by this suggestion so far.
I think DPL could be used for weapon quick references very effectively. LordBiro 13:16, 5 May 2007 (EDT)
2. Another difference between the weapons vs skill references, is the bonus effects are completely standard. Creating a 20/20 caster weapon quick reference will not introduce a column. Creating a "Disease-reduction", or even just a generic "Condition reduction" quick reference will not introduce a new column. In fact, I currently lack the imagination to think of any weapon quick references that would require a custom column. One point removed against my system.
1. Content that is hidden is simply redundant, NOT irrevalent (because of my above point that argues the difference with skill QRs). The semantics of Mesmer perfect weapons is not broken. In other words, NOT hiding the information is simply a lack of benefit, not a harm. One point removed against my system.
This puts us at a overall tie so far I believe. When/If DPL is implemented, in order to allow the weapon QRs make use of it, we will need to create individual mini-articles like "[[Kristoffir Roi/Lotus Staff (Divine Favor)]]". I know you are against the Skill template system, and while the DPL doesn't exactly use the skill template system, making weapon QRs work with it would create an effect that parallels several major criticisms of GuildWiki's template system. Does your current position of supporting the DPL means you will also support the creation of such articles/templates? -User:PanSola (talk to the File:Follower of Lyssa.png) 13:38, 5 May 2007 (EDT)
2. "In fact, I currently lack the imagination to think of any weapon quick references that would require a custom column." - I thought that this was the entire reason behind implementing the CSS, to hide custom columns. I think I have misunderstood the reasoning behind this, and overestimated the complexity of your proposal. To clarify, is this proposal just for hiding the "damage type" and "attribute" columns?
1. My above post was made under the mistaken presumption that custom columns were being hidden, but even then I did not say that the information would be incorrect, only irrelevant, which I think has a similar meaning to redundant in this situation.
If no custom fields are going to be used then I have less of a problem with the proposal. Saying that, though, I'm still not convinced that this is the best solution. Maybe DPL isn't either, but hiding columns with CSS is very unappealing to me. LordBiro 14:34, 5 May 2007 (EDT)
2. To clarify, in situations where the damage types are all the same within the table/article, and at the top of the table/article it is explicitly stated that "all weapons in this table/article deal BLAH damage", then the proposal is used to hide the damage type column. If damage types differ within the table, then column-hiding will not be used for that particular table. Ditto for attribute, and prefix (if the entire table of weapons do not have prefix, or if it is a "Vampiric weapons quick reference" table), and other columns. At least, this is my principle design of the CSS. I never imagined weapon QRs would have custom columns. However, I cannot prevent other people from using this column-hiding functionality in other places of the wiki, where column-hiding might be used for some other purposes. I can only be answerable to the original purpose I designed and proposed it for. -User:PanSola (talk to the File:Follower of Lyssa.png) 15:10, 5 May 2007 (EDT)

Resent indent. After reading DPL's documentation, and pretend that we have DPL and trying to create weapon QRs using DPL, I just realized it is pretty much irrevelant to the issue at hand. In order for the DPL to format the output, we must have all the possible necessary data of each individual weapon stored in its own page. However, by doing that, we are partially repeating what we are doing on GuildWiki with skills already - each skill having its own "data" page/template, that isn't really a normal article to be read but rather just to hold data. Once we are doing that already, trying to make DPL format the output is simply not worth it, we might as well just plug the data into a secondary template like what we did with skills on GuildWiki.

The alternate way of using DPL without using a secondary formatting template like we do on GuildWiki, would be to format the data as a table-row, then use my CSS row hiding.

Thus, the use of DPL or not does not affect prevent my CSS technique being used (though the benefits/drawbacks in that case become a slightly different list). If we are using DPL for weapon QRs, we will have to create articles (or templates) like "[[Kristoffir Roi/Lotus Staff (Divine Favor)]]", and either customize the output formatting via a nested template call like the guild wiki skill QRs (and have a different formatter template for each possible combination of information you want to show/hide), or just simply use CSS to not display whichever column containing redundant/empty data. The benefits of using CSS with DPL, instead of nested template calls, is new QR construction becomes simpler. I argue that it's very simple to specify via my CSS syntax that "I want to hide the 2nd, 4th, and 8th column which are all unnecessary for this particular table", then to create a new formatter template.

I argue that any of the options either of us presented beats the status quo (the status quo is a major cause of barrier to me getting various weapons QRs up-to-date on GuildWiki, because of inconsistent formatting of each table), and DPL does not affect the tradeoff analysis because . -User:PanSola (talk to the File:Follower of Lyssa.png) 15:38, 5 May 2007 (EDT)

I disagree with your analysis. "we might as well just plug the data into a secondary template like what we did with skills on GuildWiki" - why might we just as well? That option is pointless. We don't need "data" pages, from what I understand. Especially not for weapon quick references. For skills that need additional information regarding, for example, deep wound, it needn't be stored as a hidden parameter in the infobox, it could be stored as a section, i.e. === Deep wound === or === Deep wound notes === or something similar (deep wound is perhaps a bad example!). At least that is my understanding.
Even if we do have to use hidden parameters, that's still better than GuildWiki's hacked [edit] links and confusing structure, and it's better than the <onlyinclude> suggestions made earlier on this wiki.
For weapons you've said already they don't need any custom columns, so we could easily produce derived content from weapon articles based on their categories. If it's in mesmer weapons and perfect weapons then it should be in mesmer perfect weapons. Whether we have to create different articles (or more importantly, if different weapons have the same name but have different requirements, should they be separate articles anyway?) is something I'm not sure about. Perhaps Rezyk could shed some light on this.
Presuming that we can come to some agreement and use DPL for weapons I don't think your CSS would have as much use. From my understanding of example 2 on the DPL site it would be far easier to remove the column from the table in DPL than in MediaWiki.
Even now I would rather the columns were just removed rather than hidden. As you've said yourself, weapon information is rarely modified, just added, so removing redundant columns would be a one-off task.
As I said above, I was under the impression that this CSS was going to be used to hide custom columns. If this is not its intended purpose then I think it would be reasonable to add it (I'll wait a little while before doing so). LordBiro 04:06, 6 May 2007 (EDT)
To be clear, the "hidden paramaters" are not custom columns, but context-dependent redundant information such as "damage type", "requirements", "location" (if we are making a table of weapons found in the same location), etc etc. The "Example 2" really just moves the formatting specifications from the equivalent of "skill box qr" into the DPL call, and isn't particularly simpler in any meaningful sense. Mostly just removing a "|-" and adding some commas and "#" characters (that is, if you only want to display selective fields; if you want to display every single field then granted DPL is simpler).
Each weapon's data has to fully exist somewhere. If you put multiple weapon's data on the same page (say the Flaming Wand from collector A that is 20/20, and the Flaming Wand from crafter B that offers energy +5 while HP>50 and Fire Magic +1), then trying to let DPL pick out the Flame Wands that have HSR 20, or trying to let DPL pick out the weapons that gives extra energy, and being able to selectively display specific fields (name, acquisition, campaign etc) will be ridiculously complicated. This is because in order for DPL to be able to format it, each field needs to be tagged as its own "section", but putting multiple weapons on the same page means not only does DPL has to figure out where the "location" of the weapon is, it needs to figure out where the "20/20_location" is, or where the "20/20_damage_type" is (note: this is to distinguish the acquisition location of the 20/20 flame wand, vs other weapons you decided to have share the same page. Acquisition location and damage types etc are NOT custom-columns), where the "HSR_20_location" is, etc etc. For every single possible DPL selection criteria ("Divine Path", "unique", "requires 9 Domination Magic", "Energy +5 (HP>50%)"), you need to tag every applicable weapon's field (name, damage type, inherent bonus, prefix, suffix, location etc etc) with it. The reason you need to tag them individually is because you are saying they should all be in the same article, but I only want to select a sub-set of those weapons. If the weapons each have their individual article, then I can simply categorize individual articles as "Category:Divine Path weapons" etc etc. If different weapons ONLY have the same name, but different parameters for other stuff, it will be rather complicated to put their data into the same article and still be able to select a subset out of it depending on various criteria.
The alternative (while still keeping multiple weapon's information in one page) is to tag each weapons full data (as opposed to individual field) with all the possible selection criteria), so the DPL fetches the whole data as one single piece, then dump it into a nested formatting template call like what we did with skills on GuildWiki and let the template handle it, which is significantly less complex. This is the rational why I said "we might just as well", because it is significantly less complex. Still, this means if only one single Flame Wand has HSR Fire Magic 20%, and 100 Flame Wands don't, the entire collective article will need to be categorized in some "Category:Has HSR Fire Magic 20%" (if each flame wand is in its own article, only the flame wands that actually has HSR Fire 20% will be categorized). The result is, every collective weapon article will be in all the categorizes an instance of that weapon can possibly be in, which degenerates the categorization to solely be a tool for DPL to say "I need to parse the 100 weapons this page to find the HSR Fire 20% weapon", and lose pretty much lose its actual categorial purpose.
Secondly, if I'm looking at a weapon QR generated by DPL, and I want to edit the info on a particular Flame Wand, I still need to click on a hacked Edit link. Thus it is NOT going to be an improvement over GuildWiki's hacked Edit link, its gonna be the same. The only difference is when you edit the QR's own page, instead of seeing a list of articles being transcluded, you see a DPL call. Having multiple instances of weapons sharing one article simply complicates the formatting of the data (which can be hidden by, eh, some template calls) in exchange of having a smaller total article count, and offer no other advantages.
DPL's primary benefit is the automatic enumeration of items. You still gotta format the output via wikicode or HTML or something (even in that Example 2, the output still had to be formatted by "hacked" wikicode). If you want to remove certain columns (such as Damage Type, inherient bonus, or Prefix) instead of just hiding them, you will need to either have some three-handful of field-taggings per-weapon that the contributors have to deal with, or you can hide them via some template calls that structurally mimicks what GuildWiki did with its skills to a certain extent. -User:PanSola (talk to the File:Follower of Lyssa.png) 09:11, 6 May 2007 (EDT)

Blah, to summarize, if you are gonna have DPL enumerate weapon QRs such as "20/20 caster weapons", "Echovald Forest collector weapons", or "Condition-reducing Monk wands", then the structurally least complex way to handle it would be putting each weapon in its own page (otherwise trying to select a subset of the weapons in a page based on arbitrary criteria is gonna be quite complicated). Then there are several choices of formatting it (if you want to hide unnecessary non-custom columns such as "damage type", "prefix" etc):

  1. Using an additional formatting template call to format the output. The pro-cons are the same as the GuildWiki skill qr system.
  2. Using DPL to format the output. This is equivalent (in complexity) to using the formatting template like GuildWiki, but putting the template contents into the DPL call, slightly modified into a syntax that moves closer to the "programming language" area (compared to the original wiki code of the template).
  3. Using CSS to hide the columns, by specifying the column numbers of the respective unnecessary columns (such as "damage type", "prefix", etc) via giving the table class names such as class="hidecol3 hidecol6". Syntactically this is far simpler (in terms of character count, and ease for contributors to figure out the syntax) than removing data via DPL, with the downside that for ppl who don't have CSS enabled, they will see the unnecessary redundant data (such as Damage Type, prefix (an empty column for a table of wands), Campaign (if the table is a list of Prophecies campaign monk weapons, then that column is redundent).

In all cases, if anyone ever wish to edit the data on one of the entries, the user must click on a hacked edit link. Trying to edit the page containing the QR will never enable the user to edit the particular weapon entry. Personally, I support using DPL for skill QRs, but I'm still very hesitant as to whether DPL should be used for weapon QRs (partly because the best implementation calls for giving each instance of collector and crafter weapon its own page). And even in cases where DPL is used, I believe it should only handle the enumeration of the data, and not the formatting. -User:PanSola (talk to the File:Follower of Lyssa.png) 09:35, 6 May 2007 (EDT)

Where do you find the time to write all of this? o_o
I'm going to answer in the order you mentioned things:
Yes, I understand what the columns that you want to hide are now. It wasn't clear initially but it is now.
It will be easier, in my opinion, to physically remove a column in DPL than it is to do that at present with mesmer perfect weapons. As I said, I don't like hidcol and would rather someone just deleted the columns that are unneeded. Despite this I still said I had no problems with implementing your CSS.
Of course the data has to exist somewhere, and as I also said above, I'm not opposed to having different articles for weapons that are the same except for their attribute.
As long as when a skill is updated I can go to the source article (i.e. the skill article or weapon article) and click on the edit tab like a normal person then I'm satisfied. This is why I don't like the hacked edit button, because users must click on it in order to edit the skill details. This is not very intuitive. A note on the quick reference saying "if you want to update information please edit the skill article directly" would be reasonable imo. I just don't like the idea of someone clicking the "edit" tab (not the hacked edit link) in a skill article and not understand what's there. So IMO DPL would definitely be an improvement over the GuildWiki system. You could argue that using onlyinclude on the article would also be an improvement, and I'd be inclined to agree.
Altering the output in DPL is easier because you change one line and it changes the whole table. Seems pretty straightforward to me...
To answer your summary, as I said already, I can personally see an argument that weapons that have the same artwork but different requirements/benefits should have their own articles. If DPL can't easily filter out multiple weapons from one article, and if there's no willingness to reorganise weapons, then we won't use DPL for weapon quick references.
Putting "hidcol6" on numerous tables as on mesmer perfect weapons seems more labour intensive to me than altering the DPL code. Especially if you decide to change something. And while it might be far simpler to do, the results are not fantastic. TBH if you want to make weapon skill references using CSS and copy and paste then go for it! But I think that producing them with DPL makes a lot more sense.
No, as I said above (sorry to repeat myself) the hacked edit link itself is not the problem, it's the fact that if the user clicks the "edit" tab they cannot edit the skill details directly. They must use the hacked edit link. That's my major pet peeve when it comes to the GuildWiki template system.
Personally I think that DPL would work well with weapon quick references, even if some reorganisation might be needed, and I don't like hiding columns. I'm still going to implement your CSS. LordBiro 11:55, 6 May 2007 (EDT)
Hmm... some of your statements above may lead to contradictory interpretations. I'll try to state the contradiction so that you might be able to clarify any misinterpretations I have.
  • What do you consider to be the "source article", that people will know to intuitively go to, for a collector weapon named "WeaponFoo", offered by the collector named "CollectorBar", with a modifier "HSR 10%" (and this collector also offers another weapon also named "WeaponFoo" but has the modifier "Energy +5 (while health is above 50%)"? This is on the presumption that there are people willing to go through the crusade to reorganize the weapons to give them individual articles (and that DPL cannot easily filter out arbitrary weapons from one article). For skills, there is a universally intuitive "source" article to go to and click the "edit" tab on. For weapons, I cannot think of a naming scheme that is universally intuitive. So we might have a source article, but my fear is that the average user may not be able to figure out where it is, and in the end all of us will still be using hacked edit links from weapon QRs to edit the source article. If a source article exist, but nobody knows off the top of their head how to access it directly, and we all end up relying on using hacked edit links from one of the QRs that lists the weapon because that is the easiest thing to do (even if unintuitive, because you are not clicking on the edit tab), does your position still consider the implementation "good", merely because the source article exists?
After your explanations above, I do agree that using DPL for skills would to be an improvement over the GuildWiki system. It's its application with respect to weapons that I remain uncertain about. -User:PanSola (talk to the File:Follower of Lyssa.png) 12:34, 6 May 2007 (EDT)
As far as I understand, we would need individual articles if we wanted to use DPL's enumeration mechanisms (I'd guess that we'd then have the weapon name column link to the source article?). I'll also soon post a list of my understanding of these ideas as well as some alternate ones. --Rezyk 16:48, 6 May 2007 (EDT)
Well, if you need to go to a QR first, click on a link to go to the source article, THEN click on the edit tab, then that is just as bad IMHO as clicking on the hacked edit link on the QR. I thought Biro's preference of the DPL system for skills is because you don't need to go to a QR page first, you can just type in the search box the name of the source article, and go there and edit it directly. My fear is the average user will not be able to know the source article name for weapons (for skills it's trivial), and will need to access one of the QRs listing the weapon first, before being able to edit the weapon's info. -User:PanSola (talk to the File:Follower of Lyssa.png) 19:34, 6 May 2007 (EDT)

The options

Here's my overview of the main options as I see them. I'm posting this to try to..

  • ..make things simpler to discuss/understand.
  • ..cut down the varying, nebulous DPL scenarios closer to what I imagine they would/should be like (based on my technical understanding; you'd need individual articles for enumeration, but you don't have to rely on categorization).
  • ..inject some new ideas.

A. Where is the data for each weapon stored? (and how do other articles reference that data?)

  1. Directly within each article that uses it.
    • Pro: Simplest to understand.
    • Con: Data repeated many times across different articles.
  2. In an individual article for that weapon. Other articles retrieve the data through DPL.
  3. In a main list like "List of mesmer unique weapons". Other articles retrieve the data one-entry-at-a-time through DPL labeled section transclusion.
    • Pro: No repeated data (edit once, affects all lists). Easy to edit a bunch of entries at once.
    • Con: More complicated wikicode. Can be extremely unintuitive to find the right edit link.
  4. Use the WikiDB extension. Store the data (along with any extra fields to filter off of) in whatever is considered the "main article" for that weapon. Retrieve data with WikiDB's repeat tag.
    • Pro: No repeated data (edit once, affects all lists). Some enumerations are very simplified by filtering based on fields.
    • Con: Undeveloped?

B. How are unneeded (redundant or empty) columns handled?

  1. Hidden by CSS.
    • Pro: Controlled by one line per table.
    • Con: Users with CSS off see the wide tables.
  2. Name a different template in the DPL call.
    • Pro: Controlled by one line per DPL call. All users see narrow tables (for 1-handed and off-hand tables).
    • Con: Requires A2 or A3. Need a template for each view ("Template:Weapon row.2H view", "Template:Weapon row.1H view", "Template:Weapon row.off-hand view"?).
  3. Show them!
    • Pro: Simplest to understand/implement.
    • Con: All users see the same wide tables.
  4. Hide them by omitting them in the WikiDB repeat tag.
    • Pro: Controlled by one line per table. All users see narrow tables (for 1-handed and off-hand tables).
    • Con: Requires A4.

The discussion so far has been along the lines of A1+B1 compared to A2+B2. Some of it was a bit hard to follow, so apologies in advance if I am misunderstanding anything/anybody. =)
--Rezyk 17:27, 6 May 2007 (EDT)

Good analysis. Though the discussions earlier have also explored the option of A2+B1 (DPL enumeration, CSS hiding). Some of the over-complicated possibilities are omitted, but I'm fine with not considering those options.
  • I strictly support B1 over B3 because I consider the pro of B3 to be negligible better than B1 (it is better, but by a negligible degree), and B3's con is strictly worse than B1's con (though to be fair, it's not that bad).
  • In terms of A3, implementation of that would require each individual weapon in the article be section-tagged with all possible selection criteria. The complication can be slightly reduced by using a template call for each individual weapon, though it will remain tedious. Also, there would need to have a discussion as to what the "main article" is. Should unique weapons and collector weapons have individual main articles? If so, how can we make it intuitive for users to figure out where unique collector weapons go? If they go in the same main article, would the article be too large and should we break it down by other criteria? etc etc.
  • In terms of A1, I think "require manual enumeration of table" should be a significant con, even though the status quo also share this con. On the other hand, "data repeated many times across different articles" should be an insignificant con, at least in the context of weapon QR, because weapon stats hardly ever changes, and there would rarely need to be a need to track down all the instances of a weapon being referred to in various QRs.
Thus, IMHO, the serious options remain to be: A1+B1, A2+B1, and A2+B2. (Considering we don't even have DPL yet, something like WikiDB is really way way down the road to be considered, IMHO). -User:PanSola (talk to the File:Follower of Lyssa.png) 19:30, 6 May 2007 (EDT)
My preference is generally (from highest to lowest) A1 A4 A3 A2, and then (with lower priority than choice of A) B3 B4 B2 B1. Explanations:
  • A2 (straightfoward DPL) is very low for me because of the need to create individual articles out of every collector/crafter weapon. If there are reasons that we would do this anyways, I wouldn't mind so much -- but otherwise I feel we'd be going too far in having our data management mechanisms driving the form of our content. DPL is great if our data entries/fields naturally match with our articles/categories (skills), but if not, we're better off looking into tools that are geared toward generic data management (rather than article-as-data management) because it takes too much hammering-to-fit otherwise.
  • I think A1 is generally the way to go, at least until we've developed much more of the lists and have a better grasp of how deep the redundant-data issue is. I don't favor A4 and A3 without more development/analysis, but feel they're worth considering over A2 if we're really at that point now.
  • The problem with B1 compared to B3, IMO, is how much it opens the door for content-varying-by-viewer. I don't see this particular weapons list case as a huge deal (for various reasons), but it is a step closer in the general case to "this site requires CSS and JS to be viewed properly". I might be swayed despite this if there was a compelling reason, but the benefits here actually seem negligible as well.
It looks like we may be headed toward A1+B1 for the time being. If so, I am not objecting, although I still prefer A1+B3 at this point.
--Rezyk 18:46, 7 May 2007 (EDT)

Unlikely, but...

Any chance we can get the following code in there: 

.HopContent
{
 display:none;
}
.HopFrame:hover .HopContent
{
 display:block;
}

To see what it does put it in your Special:Mypage/monobook.css and take a look at User:Dirigible/box. Thinking that'd be a nice alternative to {{Archive-box}}. I don't have a "this is very important because..." defense for this, because it isn't. It's simply something nifty which I think looks good. The CSS above + the box are from the Cassetto2 archive box template on the Italian Wikipedia. Thoughts? --Dirigible 15:29, 30 April 2007 (EDT)

I think it's cool, but I'm not convinced it should be in common.css.
I've created an alternate version that works with the current archive box. I think it would be cool if you included it in a separate stylesheet so that others could try it out. If you can't be bothered then I'll do it, but I thought that, since you originally found the idea, I'd let you do it :) hehe. Here's my altered version:
.archive-body {
	display: none;
}

.archive-header:after {
	content: "Mouse over to see more";
}

.archive-box:hover .archive-body {
	display: block;
}

.archive-box:hover .archive-header:after {
	content: "";
}
LordBiro 04:35, 1 May 2007 (EDT)
Nice! (Finally got it working...) -- CoRrRan (CoRrRan / talk) 05:14, 1 May 2007 (EDT)

Skill infobox CSS modifications

There are some very minor modifications that I think should be placed in the skill infobox rules. On IE6 and occasionally on Firefox the gap between the green "Campaign" box and the "Profession" box is greater than the other boxes. The reason that this happens is that the dt (the box on the left) is a different size to the dd (the box on the right). I've tried out some amended rules in Web Developer and using my monobook.css skin on Firefox and IE6 and it looks much better. Here are the rules: 

#content div.skill-box dt {
    height: 1.8em;
    padding: .5em;
    width: 6.25em;
    float: left;
    margin: 0 0 2px 0;
}

#content div.skill-box dd {
    height: 1.8em;
    width: 10em;
    float: left;
    padding: .5em;
    margin: 0 0 2px 0;
}

If no one has any objections I'll implement these later on today. LordBiro 10:22, 5 May 2007 (EDT)

You've got my support. (And I guess you already done this.) -- CoRrRan (CoRrRan / talk) 07:56, 6 May 2007 (EDT)
I haven't actually. Since it looks like I'll be implementing PanSola's suggestions above I figured I'd wait and do them all together :) LordBiro 08:42, 6 May 2007 (EDT)

I've partially reverted this the recent change because it seemed to be causing problems in IE6, based on this bug report and my follow up testing. The revert appears to fix the issue in my IE6 (and I get the messed up page again if I paste this the change into my monobook.css). --Rezyk 21:26, 7 May 2007 (EDT)

Actually, the suggested modifications above seem okay; the changes that were made to the page seem to be different and problematic (IE6 only). --Rezyk 21:43, 7 May 2007 (EDT)
I tested the changes in IE6 before implemented and could see no errors. Could you please upload a screenshot of the error? LordBiro 06:10, 8 May 2007 (EDT)
I'm not sure what you mean by "the suggested modifications above seem okay; the changes that were made to the page seem to be different and problematic" the only difference between the suggestion above and the actual change is that I reduced the height to 1.5em, which was actually the value I had tested in IE6; 1.8em was an untested value that I had pasted in accidentally. I realise I should have changed the value here as well prior to altering it, but I figured that since it was such a minor change it would not cause any problems. LordBiro 06:19, 8 May 2007 (EDT)
My apologies; I seem to have somehow confused myself towards the end. Here's what my testing gave me under IE6:
  • First version of common.css, or reverted version: looks good
  • Changed version (with 1.5em): looks messed up
  • Suggested change (with 1.8em): didn't test
I'll give a screenshot when I can (probably after several hours; sorry). --Rezyk 07:03, 8 May 2007 (EDT)
Could you at least describe how it was messed up? I've browsed through a huge number of skill articles in IE6 now with the code in my monobook.css and I haven't seen any problems at all! It's quite frustrating :) LordBiro 07:14, 8 May 2007 (EDT)
I used gust for my testing. The rows were not properly aligned, each subsequent one being shifted one column to the right (I think). So "Profession" was directly under "Factions", "Attribute" was directly under "Elementalist", etc. --Rezyk 07:42, 8 May 2007 (EDT)
Try using my monobook.css? --Rezyk 07:45, 8 May 2007 (EDT)
I can see the problem! Yay! I guess when I tried it with 1.5em on IE6 yesterday the stylesheet was still cached with 1.8em... oh well! It's easy to solve anyway. IE6 seems to be rendering the box to be higher than 1.5em, but 1.5em looks great in Firefox. This is a fairly straightforward hack for IE6:
#content div.skill-box dt {
    height: 1.5em;
    _height: 1.8em;
    padding: .5em;
    width: 6.25em;
    float: left;
    margin: 0 0 2px 0;
}

#content div.skill-box dd {
    height: 1.5em;
    _height: 1.8em;
    width: 10em;
    float: left;
    padding: .5em;
    margin: 0 0 2px 0;
}
IE6 ignores the underscore symbol even though it shouldn't (the same is true of a number of symbols), in other words standards compliant browsers interpret "_height" as being a property, even though they don't know how to apply that property, whereas IE6 ignores the underscore and just reads "height: 1.8em". Alternatively I could just alter the height to be 1.8 in Firefox as well, but it would look better this way. LordBiro 08:02, 8 May 2007 (EDT)
Nice. =) --Rezyk 08:13, 8 May 2007 (EDT)

Skill progression template CSS

I would like to implement the following CSS, are there any objections?

.skill-progression, .skill-progression-header, .skill-progression-1strow, .skill-progression-row {
    font-size: 10pt;
}

.skill-progression {
        margin: 1em 0.25em;
        border: 1px solid #6A3;
        border-collapse: collapse;
        text-align: center;
}

.skill-progression-header {
        background:#ADA;
}

.skill-progression-1strow {
        background:#DFD;
}

See also Template_talk:Skill progression. I'm not the greatest CSS-artist, so if there are improvements to be made, feel free to suggest them. -- CoRrRan (CoRrRan / talk) 13:12, 7 May 2007 (EDT)

IE5 skill-box bug

In IE5, on some of the skill pages, the definition list is stacking (screenshot). This can be fixed by adding clear:left; to #content div.skill-box dt -Smurf User Smurf.png 00:15, 14 June 2007 (UTC)

Small request

At the moment I'm working on a new way to list Skills from Skill trainers. I've found a nice way to display them but to make it more easier to use I would like to add the following small code to Common.css: 

#content .hidelist ul { list-style: none; margin-left: 0px; }

It hides the bullet of each list item within an element hidelist without doing the complex looking workaround (<ul style="list-style: none; margin-left: 0px;"><li>Element 1</li><li>Element2</li><li>...</li></ul>) and gives the same method by just using * Element1. You can see an example here. poke | talk 16:33, 24 July 2007 (UTC)

Hey, Poke! That sounds fine, but I do wonder if there is a better term than "hidelist". Regardless, since this is a minor change, if there are no objections then I'll add this tomorrow (unless someone beats me to it) :) LordBiro 21:32, 24 July 2007 (UTC)
Thank you :) I have no idea, if there is any better term.. It's just came to my mind when I posted here.. Feel free to use anything else. poke | talk 22:18, 24 July 2007 (UTC)
Listless? (sorry...) My recommendation is to go for a straight class name like ".no-style" applied to the unordered list instead of the class and the sub-selector ul. What if you wanted two lists in the div? (sorry, I like to have my css be as re-usable as possible and my html as semantic as possible). Besides, the list-style property only applies to lists anyway... - Thulsey Zheng - talk 03:58, 25 July 2007 (UTC)
I see your point, Thulsey, but you can't (easily) apply classes to uls on this wiki; uls are created for you when you use the asterisk notation. Plus this div is only being used as a wrapper. If more rules were being applied to the div then I would agree with you, but as it is I don't think there's any harm in having a redundant div. LordBiro 06:50, 25 July 2007 (UTC)
I would set the margin and padding to 0 all around and let the container add padding if needed. A couple of the other skins (like cologneblue) uses padding instead of margin on the left and margins to the top and bottom. -Smurf 07:15, 25 July 2007 (UTC)
Are you suggesting the following then, Smurf?
 .hidelist ul {
   list-style: none;
   padding: 0;
   margin: 0;
 }
LordBiro 07:35, 25 July 2007 (UTC)
Yup :) -Smurf 07:38, 25 July 2007 (UTC)
I don't have a problem with that :) I'll implement it now since I'm about to go to work! Any objections, please get an admin to revert or something :) LordBiro 07:43, 25 July 2007 (UTC)
Thank you! It works :) poke | talk 11:20, 25 July 2007 (UTC)

Skill progression

As discussed here, I would like to have the follwing css code added in preparation of the new wrapping Skill progression template: 

table#skill-progression
{ margin: 1em 0.25em; border: 1px solid #6A3; text-align: center; }
table#skill-progression th
{ border-bottom: 1px solid #6A3; background: #ADA; padding: 3px; }
table#skill-progression div.column
{ border-left: 1px solid #6A3; float: left; }
table#skill-progression div.attr
{ padding: 3px; background: #DFD; }
table#skill-progression div.var
{ padding: 3px; border-top: 1px solid #6A3; }

Thank you. poke | talk 22:34, 28 July 2007 (UTC)

Could you give another example with at least 2 variables? I'm not sure if I did mine right. -Smurf 23:21, 28 July 2007 (UTC)
See my sandbox. poke | talk 23:31, 28 July 2007 (UTC)
Add this at the same time pretty please. (Or anything that'll resemble it, since it might not be the best solution to the "problem". :) )-- CoRrRan (CoRrRan / talk) 01:36, 29 July 2007 (UTC)
1) In Opera (using v9.22), the bottom 2 table cells aren't inheriting the vertical-align:top;. This can easily be fixed in the wikicode by applying it to the cells instead of the row.
2) In all the browsers I tested, when you use the Chick skin (try it) the bold columns are taller than the rest. So when the progression box wraps, the new rows don't go all the way to the left. The best solution I can come up with is to add this:
table.skill-progression div.attr
{ line-height:1.2em; }
table.skill-progression div.var
{ line-height:1.2em; }
to MediaWiki:Chick.css. -Smurf 01:43, 29 July 2007 (UTC)
I understand the reasoning behind doing this, but is there no way we can say "clear: right" and make sure it only applies when the table would fall underneath the div? This isn't to say that I don't think that this suggestion is a clever one, poke, but I'm sure you can appreciate that if there is a simpler solution I'd prefer it! LordBiro 07:57, 29 July 2007 (UTC)
I don't think that there is a simpler method - without using javascript or something like this. I'm not totally happy with it as it needs lots of divs and, as a template, lots of queries but as tables do not support any kind of wrapping and attribute level and the effect has to be bound together I see no other possibility..
Your idea to use clear: right; when "the table would fall underneath the div" is not a good solution (even if it works), the problem is not that the infobox uses to much space but that the smaller screen size of some users limits the room of the table - and this can also occur when the table is below the infobox. poke | talk 16:28, 29 July 2007 (UTC)
So what about implementing this so the problem can be solved? (btw. I thought about another solution and found one but rejected it because of the lack of css support in actual browsers :( *sigh*) poke | talk 22:46, 30 July 2007 (UTC)
(edit) for the bug, Smurf mentioned, add line-height: 1.5em; to table#skill-progression. poke | talk 22:49, 30 July 2007 (UTC)
Retrieved from "https://wiki.guildwars.com/index.php?title=MediaWiki_talk:Common.css/Archive1&oldid=424709"