Wiki Style Guide/Talk

This page is for discussing the contents of Wiki Style Guide.

Decided to make this here lest I (we?) crowd up the user pages. Earlier comments linked as I go along.

I have been making small edits to the "Website" field of various pages as I see them, generally via Recent Changes. There are no explicit stated guidelines regarding the styling of the URLs there, so I've been cleaning them up according to my personal heretofore unwritten guidelines. Just so we're clear: for the most part, this only concerns the hyperlink labels, not the itself, i.e. the stuff between <a>…</a> and not the href attribute. Seems like there was some disagreement over this last night, so... here we are.

Quoth JW, because I couldn't have phrased it better myself:

The point is to quickly present the webaddress in an easily read and clickable form, with the link being a fully qualified URL. The text of the link can be any arbitrary text. It is, however, preferable to be a form easily read and recognized. It is the portion of the link for human beings, not browsers, and thus a bit of formatting and reduction makes sense.

I would just like to add that

Hyperlinks that use URLs as label should be able to be entered into the browser's location bar as-is and still function properly. For example, if a user prints out a page, or highlights the URL text instead of right-clicking and selecting "copy link location."


As JW reminded me below, the case sensitivity is dependent on server settings (software/OS).

There are, then, three areas to consider:

Since DavisWiki does not have a separate icon for outgoing SSL links, I leave https:// alone. (For reference, I believe Wikipedia does make the distinction.) Otherwise, I shoot every http:// on sight. It should be obvious that URLs are URLs even without the http:// because

• There's the arrow icon that goes with all non-wiki-page links, so whether on print or on screen, reader knows it's a URL
  

• There's the top-level domain (com, net, org, edu, tv, and what have you) to make it all the more obvious

Additionally,

• University Identity Standards agree that http:// should be dropped.
  

• All the latest incarnations of major browsers (IE, Firefox & Co., Safari, Chrome, Opera) assume http:// when unspecified.
  

• I don't think any organizations/businesses here is going to link to an anonymous FTP account; that is, ftp:// is out of the question. Sites like RapidShare and MediaFire (and, god help us, SmartSite) have rendered them obsolete. Remember, dealing primarily with the "website" field of pages here.
  

• Tim Berners-Lee is sorry about the slashes, so I'll count him as a partial supporter.¹

I'm in the camp that believes the www "subdomain" is unnecessary, and whoever is in charge of this domain probably agrees with me (try visiting www.daviswiki.org). There are a few cases to consider here:

1. Websites that insist on faking the www, e.g. the old CSIF website. Nothing I can do about those, so I leave them be. Point.
   

Come back when you understand DNS. This isn't "faking" the www. wwwcsif is a descriptive hostname for the http server (www) on the CSIF network. Other host names for CSIF include pc1.cs.ucdavis.edu, pc2.cs.ucdavis.edu, .... which are workstations, not web hosts. The internet is not the web.... hosts are hosts. wwwcsif is distinct from the webserver for the cs department (www.cs.ucdavis.edu).


2. Websites that redirect non-www to www, e.g. the ECE department. If it loads without the www, I strip out the www. Alrighty, understood.
   

Never do this. You're linking to a redirect. Link to the actual page!


% curl -I http://ece.ucdavis.edu/

HTTP/1.1 301 Moved Permanently

Date: Tue, 25 May 2010 20:04:46 GMT

Server: Apache/2.0.46 (Red Hat)

Location: http://www.ece.ucdavis.edu/

Connection: close

Content-Type: text/html; charset=iso-8859-1




3. Mischievous websites that are simply inaccessible without the www, e.g. the toxicology department, so I leave the www intact, to be consistent with the "if printed on page, the URL still works" philosophy.
   

4. Websites that work without www. Regardless of how it is linked, I remove the www from the link label.

If there are multiple links in the section, I generally try to make the labels more descriptive (e.g. the various Costco warehouse locations, or Facebook/Twitter pages). Wait, this has nothing to do with the URL-as-label.

The more, er, controversial bit is the casing. I reserve the caps treatment for the distinguishing part of the web address: YoloCounty (domain), AgChem (subdomain), and MootCourt (directory). I personally find it more eye-pleasing and aids in recognition. Putting in spaces would invalid the don't-break-copypaste clause.

Though I would concede that, as far as case is concerned, some edits do lean closer to case nonsense — in my defense, the (my) inconsistency arises largely out of the absence of official/community-agreed standards, and there are only so many what-did-I-do-last-time cases that I can keep in my head.

• Those are outright errors in most cases under the "it should work on a printed page" rule of thumb. Or at least in most sites, the path is case sensitive. It appears that the first case actually does work, but the second... if you type it as it is, it fails.
  

• Ack, you're right... I've been living in the mod_rewrite environment too long, and IIS/Windows isn't case-sensitive. So directories are kept in natural case then.

With that said, I suppose I shall hold off on this area of nitpick/micrognoming/peeing all over the wiki till we come to some sort of consensus.

Thoughts?

Note: You must be logged in to add comments

2010-05-24 22:25:23   In general, I think removing the http:// makes assumes people are stupid and makes stupid people out of those who aren't. With regard to the wiki in particular, I think it is questionable to assume that people understand the meaning of the arrow, and with all the new top level domains, people might not recognize the URLs for what they are.

On another, but semi-related topic, if we observe that http://www.something.tld/ currently forwards to http://www.something.tld/index.html , we should still keep the link as http://www.something.tld/. The reason is that these forwards often change while the domain stays the same, and our links will be more stable if we keep leave the page out of the URL (unless, of course, we want to link to a specific page). I bring this up because I have recently seen some changes that added a page name to the main URL, and I think this is a mistake. —CovertProfessor

I just think it is redundant specifically in the header field labeled "Website". The arrow icon never entered my head when I did them. It's the fact that there is a whole word above it that states what the following bit of information is. Shall we also notate mailto: for the field under Email, and telephone: under Contact? It is the redundancy of the labeled field and the labeled scheme that makes it seem unnecessary to me. The two lines are basically saying: "the website address is website address davishijinks.com". As for the body, unless the actual address itself is being discussed, I think it should ideally be contextually linked into the text itself. Although this particular conversation is probably moot... the Style Guide is not really a way to make style, just document what is common. It's a Field Guide to the Wiki... adding a new bird does not summon that bird into existence. I doubt William will stop readding the http:// to the Website field, and when I'm creating an entry or editing the header, I'll probably de-redundancy the header along with removing the parens around fields, or the (s) from Owner(s) when people add correct info but leave them in there from the template. -jw


Small note: I stuck this under wiki style guide because it seemed like the most appropriate place. —ebt

2010-05-25 12:27:52   This is so stupid, I don't even know where to begin.

1. There is no case sensitivity in DNS. Making cutesy crap to exploit this is annoying.
   

2. CASE DOES MATTER IN PATHS! DO NOT HAVE A DIFFERENT CASE IN THE LINK TEXT AND THE LINK. THESE CAN POINT TO DIFFERENT THINGS!
   

3. If a link has www in it, the link text needs www in it as well. We're pointing to a HOST. Specify the host! What is this web nonsense you speak of? If there is no www in the actual link, then fine. But don't have the host in the link text URL different from the link. Again, THESE DIFFERENCES MEAN THAT THE LINK AND LINK TEXT CAN POINT TO DIFFERENT THINGS!
   

4. By default, links without linktext display http://. If you think it should be changed, go complain to philip, but don't do cutesy crap to get around your hatred of explicitly listing protocols.
   

5. Really, this whole thing is just more work. What's the point? So I edit a website address and need to update the actual link and the cutesy "human-readable" equivalent? —WilliamLewis
   

• As I said above, "I doubt William will stop readding the http:// to the Website field". -jw
  

• I agree with wl on all points. —cp
  

Your response is so bursting with emotion, I don’t even know where to begin either. Cutesy. I’ll start with cutesy. I don’t see this as “cutesy” at all, but even if it were, is it really necessary to slap that label on this suggestion with contemptuous intent just because you find yourself disagreeing with it? That was rhetorical; obviously your answer is yes because you already did so let’s move on... to... case sensitivity. Yes, I am now aware that case does matter for paths, as JW kindly pointed that out to me above, and I stand corrected. That was hours prior to your response; thank you for the thorough perusal. Maybe that’s why I crossed out the directory example, who knows? Shrug!

Contrary to your impression of my motivations, I do not have a deep-seated hatred of explicitly listing protocols. If you’re referring to the “shooting on sight” remark, I apologize for using overly colorful language. I sometimes forget that not everyone shares my appreciation for embellishments when reading/writing extended passages of words.

“This whole thing is just more work.” How? Nobody is beholden to anything. I made this page under the wiki style guide for lack of better location, but as far as I know, none of it is obligatory. I don’t hunt down every single instance of the website field on this wiki to edit; I just change them as I see them show up in others’ recent changes (for the most part). If you add a website address, it’s fine to leave as it is. Mission completed. It’s a link and it works. No argument there. But I don’t see anything wrong with making it even more human-readable. Though if you want to dig through my entire edit history and revert everything to what it used to be while pasting the vague “URLs are URLs” comment into each and every single edit comment, then yes, I suppose it really is more work. Actually, yeah, if you end up doing that, I apologize in advance for whatever important life-changing experiences you may be missing out on because you had to track down remnants of a cutesy insurrection led by some rogue gnome.

This page exists not because I’m trying to recruit infantrymen for my nonexistent crusade against unkempt link text, but because I noticed that certain fellow editors do not share the same perspective as me, and I decided that the best approach to dealing with the situation would be to take some time to justify the reasons behind my edits. There have been some benefits. I approached the web from a graphic design/copyediting background, so naturally, there are some intricacies that I inevitably neglect. I think you make a very good point explaining the wwwcsif case, as well as directing my attention to the 301. What I don’t see is the value of “Come back when you understand DNS” bit; that is, while I don’t expect you to teach me how to breathe and crawl, I cannot imagine what compelled to you prefix your explanation with those words. If you would prefer that I stay away lest my ignorant fingers soil the content, sure, I have no qualms with that. I’m not really here for information; I emerged from the lurkers’ shadows because I witnessed people making a cooperative effort to document every detail about their community and figured it worthwhile to jump in and lend a hand, perhaps even, oh I don’t know, pitch a few ideas of my own and work it out with the rest of the editors. If my suggestion is so preposterous that it enrages you, I’m fine with dropping the issue altogether. I see no benefit in driving up the blood pressure of a fellow editor.

Even if you don’t read every word of my response, I’ll admit, I’m grateful for this learning opportunity you’ve given me — it’s not every day that I get a chance to handle a volatile fireball without wearing oven mitts. (Hope you don’t object to the hair spaces surrounding the em-dash.) Have a nice day now. —EBT