User:A Knight Who Says Ni/Essays

Formatting line breaks

The lines in this box are separated by 4 different forms of the break code.

The code to insert a link break can be specified in four ways: <br>, </br>, <br/>, and <br />. All four work just fine, but only the first is shown at WP:NOWRAP (which is not actually a Manual of Style page, but MOS points to it, in lieu of giving direct instructions about the break code), and at HTML element (a page about HTML-like codes as used at Wikipedia), and it is also my preference, just because it's the simplest. I have seen instances where a bot has mass-changed <br> to <br /> in articles, and when I asked why on the bot's talk page, I was given a lecture that <br> is improper HTML coding, because it is a tag that cannot be closed, and all HTML tags should close.

I disagree. First of all, we do not use real HTML at Wikipedia, but Wiki Markup language (Wikitext), as mentioned in the NOWRAP article above. Wiki Markup is an imitation of HTML, created for the convenience of users already familiar with HTML codes. But Wikitext does not necessarily have to follow the rules or trends of real HTML. Second, the contention that all HTML tags should close, was not part of the original HTML design (otherwise, the break code would have been a closed tag all along). After HTML had been around awhile, developers noticed that most HTML tags close, and the few that don't could be modified so they do, and so it was proposed that this be a standard in future. This is a proposal that has yet to be accepted, and probably never will be, considering the widespread use of all four versions of the break code on the internet.

Even so, it's a point-of-view issue that people feel strongly about, and some computer science instructors may preach that certain coding practices are improper or are to be discouraged, to push their own standards which are not universally accepted, and the bot creator I talked with may have been influenced in this way. (For example, the HTML manual I use suggests avoiding tables in web pages, because "some Web browsers do not support tables" — Whaaa???) Getting back to closed tags, there is enough support for views like this, that a newer standard called XHTML has been created to eventually replace HTML, and it has stricter rules, including removal of all versions of the break code other than <br />. Despite the intentions of the creators of XHTML, it seems unlikely that it will replace HTML, or become as widespread as they had hoped, and its stricter rules are one of the main reasons (see the "criticism" section in the XHTML article).

I have asked around for opinions about this at help pages such as the Village Pump, and others have agreed that there is no need to arbitrarily change one format to another in existing text, and there should certainly be no bots going around making this change. Unfortunately, telling a bot owner that his bot should not be doing something, is advice likely to fall on deaf ears. Similar concerns about unnecessary bot-driven changes have come up in the ongoing debate over date linking.

Using line breaks in infoboxes

List with commas Item1, Item2, Item3, Item4, Item5, Item6 List with breaks Item1 Item2 Item3 Item4 Item5 Item6

A related concern is the formatting of any infobox field containing a long list ("long" being more than two or three items). While using line breaks will make each item stand out, it is questionable as to whether this is desired in a long list. In my opinion, a list of items separated by commas is preferable, the theory being that long lists are rarely read, and are only included because infobox instructions say they should be, and in these cases we should strive to keep the area to a minimum vertical height. Others have agreed, but not everyone. At the Pink Floyd article, the list of band members at the bottom of the infobox has been changed and reverted frequently as of late, between commas and link break separation methods (in addition to changing the order of names, moving some or all of the list from "past members" to the "current members" field, and removing early member Bob Klose whom some feel should not be mentioned). Have a look and see what state it's in at the moment! Regarding the order of names, and other issues mentioned, we follow the infobox rules which cover all these questions.

One of the first "techie" changes I made at Wikipedia came about when I noted the instructions for the Musical Artist template said items in the "genre" field may be separated by either commas or breaks, while instructions for the Album template only mentioned commas. I decided to be helpful by copying the exact wording from the former to the latter, with edit summary: "Copied a detail from Template:Infobox musical artist for consistency". I was immediately reverted and told off! It turns out there was a big argument over this previously, and the Albums WikiProject decided they don't want to allow line breaks in this field, even if a very similar WikiProject's infobox does. A recommendation about advising one method or the other, depending on the length of the list (just like I've suggested above, but this discussion happened long before I knew about it), was apparently discussed at both WikiProjects and rejected. It just goes to show that you need to check for previous discussions and concensus before assuming a change will be welcome, and that a rule estabished at one place does not automatically apply to another. The best advice is: if you're not sure, ask first.

Formatting ref names

To put it simply: you do not need to use quotes when giving a reference a name so it can be used later. The following works just fine:

<ref name=fred>This is a reference.</ref>

which can be followed later by: <ref name=fred/> to reuse the reference without restating it in full. (An optional space may separate the name from the slash which follows.) The name should be appropriate to the reference (so please don't call your ref "fred"), and should be short: a single word with no spaces, punctuation, or accented characters; just the standard 26 letter lower case alphabet plus 10 numerals, kept down to 8 characters or less. (If you use a capital letter in one place, but not another, they are regarded as two different names. The best solution is to just avoid caps, even if referring to a proper name – like Fred.) Apparently, the ability to use quotes and mixed case was added for the benefit of users who want to use longer or more complex reference names. The question is... why? (Why would they want to, and why should we allow them to do it?)

Two of Wikipedia's instruction pages, WP:Footnotes and Help:Footnotes, state in passing that quotes are not required around the ref name, but show quotes in every example. As a result, quotes are used more often than not. And when questions come up on talk pages about how to format a reference, new users are always shown an example where quotes are used unnecessaarily. Whenever I see this, I've tried adding a note that the quotes aren't needed, and ideally should not be used, but I haven't seen anyone else follow my trend.

The "genre" field in infoboxes in articles about musicians, albums and songs

I wrote the following during a discussion at the Pink Floyd article, and have since copied and pasted portions of it where other debates on genres have occurred. I really think this covers it thoroughly, and have yet to see anyone disagree with it – aside from extreme deletionists who want to do away with genre indentifications altogether. I have never created a help article at Wikipedia, but if I ever do, this will probably be the one to start with. The text which follows is exactly as I originally wrote it, and retains comments specific to Pink Floyd, which would of course be removed from a more generalized genre guide. (And by the way, the "proposal" was agreed upon, and is now the standard for Pink Floyd and their albums.)

Genres in Pink Floyd articles are frequently changed (and almost as frequently reverted). It's time we had a policy about this. I have a proposal, but I'm going to put a lot of preamble first. (Sorry if this becomes long-winded, I'm sure it will be!)

• I'm a big proponent of discussing policy changes like this before implementing them, therefore, please wait for consensus before proceeding with changing articles to match these proposals.
• Genre changes tend to get kicked around like a football. Decision A gets changed to B, then to C, then to D, then unwittingly back to A. Wikipedia edits are supposed to gradually evolve toward a stable ideal; most genre changes do not, until a policy is brought in. Once a decision is made, we can feel free to revert changes and point to the policy in edit summaries.
• A few months ago, genre fields were removed from the infobox, then put back. There was a big controversy over this, and it's one where all sides had a point. Some opinions (which I agree with) expressed during these debates:

• Infoboxes are intended as a summary of the content in the article. If the genre field (or any field) has items which are not mentioned at all in the article, the field is being used improperly.
• An article can mention one genre in the infobox, and multiple sub- or additional genres in the body of the article. Many articles tend to do the opposite.
• Most of the time, one genre per infobox is sufficient. Some guidelines for picking the best genre out of many options: pick one which is the most all-encompassing, or which reflects the style of music the group is best known for (at the time of the album, if it's an album article). For example, progressive rock is a very wide field. It can include the experimentation of A Saucerful of Secrets, the fusion of orchestral and rock music in Atom Heart Mother, the sound collage found in The Dark Side of the Moon, and the folky songs on More. These sub-genres can be mentioned in the body of the article, and "progressive rock" can be a summary of them all, for the infobox. During the time of these albums, Pink Floyd were regarded as a progressive rock band, regardless of their dabbling in other genres on any given album, and this fact should also be a guide to the genre used for album articles, as long as there is no compelling reason why that categorization should be considered inappropriate for a particular album.

Considering the above, here is my proposal:

• Pink Floyd presented themselves as a psychedelic music band in 1967, and this term best fits their first album. This should be the only genre in the album infobox.
• In 1968, Pink Floyd changed into a progressive rock band, and this term best fits the albums for the remainder of their career. This should be the only genre in the album infobox.
• As A Saucerful of Secrets is a transition album, containing left-over material recorded with Syd Barrett, it would be appropriate to make an exception and list both genres in the infobox. The same would be true for compliations with a significant representation of Barrett and post-Barrett material.
• As for the main Pink Floyd article, it currently lists 4 genres: progressive rock, psychedelic rock, space rock, art rock. The first two are fine, and I like them in this order (best known and longest lasting first), even though it's not the chronological order. "Space rock" is disputable. Pink Floyd are often regarded as pioneers of space rock, but is it really true? I recall a quote from Roger Waters that dismisses "Interstellar Overdrive" as space rock; he says it's just an instrumental, and only received its connotation when it was given a title some time after it was written. Lyrics for "Astronomy Domine" and "Set the Controls for the Heart of the Sun" are definitely space rock, but can a large percentage of their work be so defined? For every song with spacey lyrics, you could probably find ten ordinary love songs. I have no objection to the genre being discussed in the body of the article, as it already is. As for "art rock", I suspect this is a label that was applied to Pink Floyd in their early days, but is regarded today as the roots of progressive rock. This is something that can be mentioned in the article, but is a duplication of information in the infobox. Therefore, I propose removing the latter two items, with an explanation of the "art rock" label added to the article.
• These proposals are intended for band and album articles only. Individual songs from albums can be in a completely different genre from the album as a whole, and it is not appropriate for us to have a general policy for this. (Although, we can have policies for individual songs, on song article talk pages.)

Here is a follow-up post I made at the WikiProject Music talk page, giving advice on dealing with genre changes. It repeats some of the opinions above.

The subject has been discussed, but the people "fiddling" with genres have never read it. Here are some thoughts:

• Most edits to articles are supposed to bring the article closer to an "ideal", but genre changes often go in circles. Choice A gets changed to B, then to C, then back to A, and then around again. Don't stand for genre changes that aren't getting nearer to an ideal.
• I frequently revert trivial genre changes with edit summary, "Please discuss your reasons for wanting this change on the talk page". The editor rarely bothers to do this. I presume he thinks about what argument he could make for the change, and realizes he doesn't have one.
• Everything in the infobox should also be in the body of the article, because the infobox is just a summary of points from the article. If someone wants to add "blues fusion" and there is no mention of this term in the body of the article, that's a good reason to revert.
• In many cases (the majority, I think), one genre is sufficient.
• A genre for an album should not attempt to include the genres of every song. Pick one over-all genre that covers the work as a whole. "Psychedelic" would be a good genre for the Beatles' Sgt. Pepper's Lonely Hearts Club Band even though it also contains a piece for chamber orchestra, an Indian raga, and a soft shoe number.
• Usually there is a genre that covers a lot of others that people would want to add. For example, "progressive rock" covers a lot of ground, including experimental rock, etc. I often revert attempts to attach extra sub-genres to prog rock, and say, "Prog rock already covers this, one genre is sufficient".
• I don't mind if the body of the article lists 10 genres, and the infobox just lists one, choosing the one that covers the most ground, as above.
• Beware of "fusion" genres listed on their own. Meaning, if someone adds "avant garde" to a rock band or rock album, it usually means "a slightly avant garde side of rock" and is completely different from "real" avant garde which is a product of classical music composers. We see the same thing with "blues" and "jazz" when referring to a rock band that is only a little jazzy, or plays rock arrangements of blues songs, a la Led Zeppelin. Genres should fit the proper definitions as explained by the articles that describe these terms.
• Another one to watch out for is "acid rock", which some editors will add to songs with drug-related lyrics, or music that bears little resemblance to the American West Coast sound circa. 1969, which is what this term properly references. I frequently revert this change with edit summary, "It doesn't mean what you think it does; read the article".