Tag Prefixes Let You Do Server Things

Sharepoint is a weird agglomeration of technologies, built by a massive team of people, and it tends to need some handholding for the sake of its own security. Much like yourself, when you think about the hollowing of the middle class, wonder how you got here.

So, coming from a raw and rather old-fashioned web development background, where one might be accustomed to installing LAMP and going for it, what is a Tag Prefix?

As far as one can tell, a tag prefix tells your Sharepoint frontend page or layout to expect weird tags to turn up, which call specific underlying functions from a given document reference/the appropriate MS namespace. That's it, and that should be all, except they frequently have registration problems; "Unregistered Tag Prefix" as an error means that there is a tag somewhere in your page that is calling to a prefix that has not been properly entered up top.

Tag Prefix: a way of bringing access to various server controls into a front-end dev space.

The tag prefixes explicitly tell your page what things your page is allowed to call, presumably to protect your server and make sure everything is running the way it should. If you read the tag prefixes on your page, you can usually tell what functions are permitted within the page.

This means your page won't choke when it runs across <SharePoint:ListProperty /> somewhere within it, and, should you be genuinely writing your own libraries - which, should be stressed, you will probably not be doing if you're mostly helping people use the calendar function - you can make your own.


This is where a more professional blog, such as one that hearts the heck out of Visual Studio, would point out that you can develop in VS2010 and deploy things as Solutions to Server Farms and that Solutions come with a Manifest, but I do not drink kool-aid, I drink gin, so here, a very simple custom tag prefix use:

<% Register TagPrefix="booze" TagName="gin" Src="~/UserControls/TheBarCode.ascx"%>

This would allow you to call delicious <booze:gin Title="drink" runat="server"> and then you'd be fired forever because gin + servers = juniper-smelling magic smoke. The most exclusive only. It will take your whole budget to smell it even once.

Probably Visual Studio is coming into this soon. To the horror of all involved.

PS: I got Reddit'd. They said you shouldn't listen to me, because I am grossly inexperienced and deeply unprofessional, with many Wrong Answers, and that I should read more and blog less. Accurate!

Secret Words: Project Title for Your Page

By now you are aware that there are a million ways to do anything in Sharepoint, and that the published Best Practices have nothing to do with actual Practice. This is okay. Here are some Secret Words. You want them, because without them, you will hand-edit every page title.

These are the Secret Words to call up the property for your current subsite's real name, as in the Title for the  subsite, as versus for the page itself. 

 <SharePoint:ProjectProperty Property="Title" runat="server" />

This is distinct from what the edit panel lets you change:

<PublishingWebControls:EditModePanel runat="server" CssClass="edit-mode-panel"><SharePointWebControls:TextField runat="server" FieldName="Title" /></PublishingWebControls:EditModePanel>

The former just sticks the site's actual title on your page. The latter lets you edit the page title field. The more you know, the more you want to drink bleach. Happy Monday, here's a PJ Harvey video.

Reading Off The Web

By now you have worked out that pure Sharepoint content is not the point of this blog, no matter how I try to keep it on-topic. But then, it was named for one of those things that happen out in the real world, a cross-pollination, as it were. This is more to do with what happens when a straight arts and lit person discovers they are pretty good at puzzles, uses this ability to strip the skin off the systems running the world for money, and is, accordingly, horrified at what lies beneath.*

*Disorganization and people, mostly.

In order to escape the horror that is realizing the people who made these systems are, for real, people, and the biases are now hard-coded, I have become a reader. Readers have book lists. Other people know they're readers, and ask for book lists. Some of mine are long enough to reveal my profound disappointment with reality as it stands; this is not one of those. This is my short list.  Most of these are pop culture or pop science. All of them have roots in quite recent research or benefit strongly from broader background reading, but stand well on their own.

All of these are affiliate-linked, of course. But you can probably find them in the TPL, and I recommend you do so.

1. vN, Madeline Ashby – Read this book! She’s local, it’s recent, it’s AMAZINGLY WELL DONE for a brutal story about all the weirdest bits of the internet. SO GOOD.
2. Burning Your Boats, Angela Carter  – the collected short stories: I’d been recommending The Bloody Chamber to all and sundry, and, truly, it deserves it – but this has all that and more.
3. Mauve, Simon Garfield – the history of organic chemistry through the development of artificial dye.
4. Stiff, Mary Roach – What happens to people when they are no longer people, per se.
5. Fun Home, Alison Bechdel – memoir is everywhere. This one is an excellent graphic novel.
6. Stolen, Annette LaPoint – not for everyone, but for most people; a novel of the praries and contemporary geekdom and theft and murder.
7. Gun Machine, Warren Ellis – Again, the violence may be too much, but I loved it.
8. The Information, James Gleick – A survey of the history of information as quantifiable product. I’m reading it for class, but why shouldn’t others benefit?
9. Zero History, William Gibson – the ending is a bit weak. I like his writing anyway. I want to live in that world.
10. Ready Player One, Ernst Cline – I was ambivalent to this but in the end re-read it twice. So I suppose, if we’re going to Other Worlds…

Approval Workflows

Today we are customizing an approval workflow, which lets us peer into the bleak soul of the task assignment system. We are doing this through the lens of allowing people to request vacation time without filling out two copies of a form and asking for manual signatures on those forms.

Signatures: Good for cheques - someone should see where the money goes - bad for routine chores.

The first thing you will need to do is create a new subsite and set it up to handle calendars. Then add a calendar. Set up two groups of people in your permissions, one who can ask for things, a second that can approve things. Reflect that Sharepoint prefers groups, though you sure don't.

Got it? Good.

Calendar created, you need to get it to trigger a workflow programmatically to send things to the correct people. This will require a custom content type, so you can attach a name to a vacation request, and a workflow.

In Browser: Custom Content Types

1. Site Settings >> Galleries >> Site content types
2. Tiiiiny thing that says "Create" right there at the top
3. Make your new content type, have it inherit from Event.
4. Set it up as part of your custom content types group
1. If you don't have one, make a new group and put it there.
5. Head to your calendar.
6. List Settings.
7. Content Types
1. Add From Existing Site Content Types
2. Add your custom content type. I called mine Vacation Request.
1. Why-eeee?
2. This means that when you click "create new," something called "Vacation Request" will be available in your list of New Things Available, and this will make everyone in your office think you are a genius.
8. Your Custom Content Types will only be available to your subsite unless you create them on the main site level.

They spend whole marketing presentations on this $h!t in the corporate world. Really. Thousands of dollars to rename an "event" a "vacation request." JOB. SECURITY.

Workflows
Workflows seem super-accessible and intuit- no. No they don't. Because graphic scripting engines are weird and because they can be added to any list item from about three places, workflows are heinously counterintuitive.

There are lots of "reusable" workflows in sharepoint, but they're not really reusable in any way that makes sense.

You can attach some to your calendar via the calendar page itself, edit "workflow settings" and good luck to you because these things are recursive and strange. Better: write your own via Sharepoint Designer.

1. Open SP Designer.
2. Navigate to your subsite.
3. Open your specific list. 
4. Look for the little window that says "workflows" and is empty.
5. Create a New Workflow
6. Add an "approval" by adding a step, and from the action menu, adding "start approval process."
7. You can then customise the thing specifically to accept or reject whatever.
8. But your rejected vacation requests will remain in play because rejected documents are thought to be good for editing. You need that cleaned.
9. Add a second workflow*
• *Sharepoint ain't give a fuck 'bout efficiency. You can, in theory, do this all with one. Do not bother.
10. Add a step and load a condition: If Current Item:Approval Status equals 1;#Rejected
1. Add the result: Delete item in Your Calendar Name
11. It will pop a warning, because selecting that way will wipe any rejected item in that calendar, which is sometimes not preferred in larger document libraries but works fine for us.

So this is pretty straightforward, and it remains so as long as you do this kind of design, custom, every time. You can, in theory, build great reusable workflows. But as you can see, at least part of the clearing-out-ness requires a specific calendar name, and we have built this thing in a specific subsite. 

The other ways of doing this take three pages of writing and a quarter of gin. Just do it this way. It is the least painful.

Custom Layouts 101/LOL

Custom Layouts are one of those things you make once in Sharepoint and then never touch again. There are a lot of those things in corporate information design, which leads to much tut-tutting by consultants, but, for real: changing these things one they run well is made-up work. It is upsetting to your users when things change for no particular reason, although I suppose it might make them happy, briefly, to have a new logo, before they stop seeing the logo entirely because it relates not at all to their job of finding and editing the new loans agreement paperwork. Please be damn sure of your actual value addition before you start shoving things around from Tuesday boredom.

There are two basic views of a Sharepoint page, Edit and Read. You are the primary user of the Edit Page. Your user is the primary user of the Read Page. Your life goal is to be able to create a new splash page with all relevant bits and pieces in place in under ten minutes, that you can go back to writing your MFA on information theory and watching drones play catch on the internet.

Can I Create A Homepage That Automatically Pulls In, Say, A Calendar View And A Discussion Board?
No. You have to activate those as Site Features - templates that are available in your subsite - then create the relevant lists before you can call them. I expect you could program a custom Site Template that automagically turns on the appropriate Site Features then loads your desired List Types on the press of a button, but then you would have learned something and possibly have to admit to being Wrong About Sharepoint After All, and that cannot be.

Layouts are initially designed from the back end, in Sharepoint Designer, then pushed live, where you can include the most relevant webparts. There are some parts you can include back-end - anything that speaks to an extant list already loaded on your site, all content query webparts, that sort of thing - but you can't include views of document libraries or calendar lists, so you're pretty well just boned from the POV of backend development saving you front-end time.

Webpart You Can Have

File under Nice Things - you can have anything that rolls up data that's guaranteed to be there already. So things like the Content Query Webpart are fine. This is also where you'll be working with custom list-view webparts, may Satan have mercy on your soul. I like to force everyone in the company to see today's general announcements list, because secretly I am a reptile.

How To Backend Hurr Hurr Hurr
Do you have Visual Studio? Great, you're too competent for this blog, go away.

1. Open Sharepoint Designer 2010.
• 2007 had so many security holes many places refused to load it at all. 
2. Under the Master Page templates will be Page Layouts
1. Wait it's not there!
2. You made your site using the wrong sort of Site Template. 
3. Proceed directly to jail, no GO, no $200.
3. Find a page layout you kind of like by clicking around and wondering about yourself.
1. This will cause SPDesigner to lose its shit and try to crash.
4. Copy it and rename it "ProjectLayout" or whatever you will remember.
5. Edit This File, check it out, set your view to Split because this is like Dreamweaver, where you're going to learn to interpret their GUI gestures in both code and real time.
6. The code section will be yellowed out to protect the worthy. Select "edit in advanced mode" and it will go normal. Some things will realign themselves.
7. There are a lot of tags here that make no sense if you're used to semantic code.

Okay, so here we go: none of this makes sense or is documented in a really coherent way anywhere I have found it. There are certainly books you could buy, but you're at work already, so! Fun times are to be had. Know what you want, kind of? Great. You should create a subsite for yourself and begin applying random-ass page styles to it until the thing you want shows up. Yes, really. Then load the appropriate page layout into Sharepoint Designer and find the appropriate Secret Words, steal them, and paste them into your new layout.

Other Pointer: Do you remember when you loved semantic code and <DIV> tags and styling sites with CSS to float things around the page? Because I do not. Tables are your new friend, as whomever wrote this software was really big on tables. They are the simplest route to having web parts show up roughly where you want them, and as Sharepoint does not give a single fuck about bandwidth, usability, or mobile, you'll be just fine.

The below is a sample of a bog-simple page layout, but without any of the masses of tag prefixes you need to get the thing to run. As you can see, I do most of my customization in the browser itself, because my clients are not fond of shiny things and would much prefer to see, say, their calendar and their documents in the same page. Enjoy.

Web Parts, Why-eeee

Web Parts are things people have written that plug into the more front-end portions of the Sharepoint infrastructure. They are used to control and display your back-end information. Although there are a plethora of them, in practice you will be using only one or two. These are the Content Query Webpart, in Sharepoint 2007, and Are All Of These Actually The Same Thing? in Sharepoint 2010.

Sharepoint 2010: Drop A Block In the Page and Call It A Day
All lists (everything is a list in sharepoint) can be displayed as webparts, which are functionally tiny windows within windows with their own display settings. Each list you have on a subsite automatically generates its own page, with a webpart in it, which displays the content of the list according to settings you choose in the toolbar, hopefully while sober and lacking the flu.

Document libraries, calendars, everything - you set what to display on their page, and then all future views of the list will just load those settings, correct?

False.

Those settings are not centralized, they are page-specific. That means that every time you need to load a given view of a list into a page, you're gonna be setting how you see that list. Even if it is an extremely specific set of preferences about, say, group selection and display.
JOB SECURITY.

There are ways around this - for example, setting everything on the one calendar page and then exporting the webpart with all its settings, and loading it to whatever page you end up with - but in practice, this will lead to you storing hundreds of XML files with various almost indistinguishable webpart settings, which you use in two places on your site; the first where you made it, the second on the landing page for the subsite. Not particularly efficient in real terms.

So in practice,  you get to hand-edit every homepage, and prepare to answer a lot of questions about where the documents are actually living. This is marginally better than managing check-ins, and slightly worse than sorting out version control.

Performance Management Easy Achievement High Score
Do you need to game a performance management system in advance of Spring Review? Oh shit you might. Great. Customize twenty of the damn things and stuff 'em in a folder and then you suddenly have quantifiable job metrics for data-driven review. Well done you. Your horrific cynicism will carry the day yet.

Hiding The Toolbar in Sharepoint 2010

The Toolbar is one of those in-between metaphors in the Sharepoint 2010 environment. It is designed to make things more comfortable for people used to Office 2010, yet it makes using a web metaphor complex and somewhat needlessly difficult. Here is how you hide it.

Why You Want To Hide It But Not Pull It Entirely
Really, Sharepoint is constructed to rely on the damn thing. Unfortunately, if people don't have permission to do shit on your site - and most of your users are readers, not contributors - you don't really want them poking around the various grayed-out links.

1. Pop open Sharepoint Designer and find the site you need to get into.
• Side nav - Master Pages
• Your custom master page from when you wiped the basic sharepoint page.
• Edit file
• Check out the file.
2. Look for this tag: <SharePoint:SPRibbon runat="server" PlaceholderElementId="RibbonContainer" CssFile="">
3. I like to label mine things like <!-- === THE RIBBON STARTS HERE == --> for future reference, but all that should be in your minimal master page.
4. The next thing to do is decide what permissions people should have before they can see your ribbon. I like "edit list items." 
1. <Sharepoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControl2" runat="server" PermissionsString="EditListItems">
2. every other piece of ribbon content goes in here.
3. </Sharepoint:SPSecurityTrimmedControl>

So how does this work?

Permissioning is still your only job. You now have two groups of users, Everyone, who have read permissions and can't touch anything on the site, and whatever group you assign to have other permissions. In theory, this will work to control the whole site - the ribbon will just not be there when they log in. 

Sometimes You Just Need To Trust People

However, this means that you need to grant pretty high permissions to anyone who wants to edit anything on the site, and that includes things like, say, a calendar. For some reason, presumably because the ribbon is set at the master page level, you can't just issue edit list permissions on a specific list (everything in sharepoint is a list) and have the ribbon load properly on that list alone.

In theory, there is a provision for this by "allowing" people to "hide" or "display" the ribbon.

In practice, for the group you want to be able to edit and access that calendar (or list generally), create a group, give that group Edit List permissions on your site, and trust in the panopticon to let you know who, exactly, fiddled with what. They probably won't, you can definitely see what they did if they do, and turn on version control for the site. Welcome to systems administration, which - much like the future generally - is slightly less than promised.

How To Remove Drop-Off Libraries

As previously discussed, Sharepoint automatically creates a tin-eared list of nonsense whenever you turn on or change any aspect of its development. Some of this stuff looks useful when it arrives, and my favourite of these is the drop-off library.

Why Remove The Drop-Off Library
Drop-off libraries are supposed to be document routing catchment basins. People upload a document and fill out some metadata, Sharepoint routes the docs according to rules set up by the admin who runs the thing. The documents go to somewhere retrievable, possibly for long-term storage. It relies on computers doing things automatically, which sounds fantastic and should work really well.

Sadly, should you set up a drop library to accept a document in an anonymous way, then someone uploads the document without metadata, the upload won't fail.

No. It will upload a doc without metadata, kick the event handler, and leave the doc in the library, issuing No-Metadata warnings periodically. Should someone then fill in the metadata, the event handler then does not re-kick. No. The document simply becomes public to whomever can see the thing. Approving it also does not kick the handler. The handler is asleep. The content router is therefore of only moderate use; you will be writing your own event handlers and your own Byzantine submission guidelines, or you will be hand-picking your permissions settings.

In cases where you've been asked to do both of these things, you will want to get rid of the drop-off library.

The Drop-Off Library is protected and comes sans the Delete This Library link. Which you need.

There are a number of blog posts on the internet about how this is very straightforward, as you can use the Client Object Model, PowerShell, or Sharepoint Manager 201x to do this chore, which must be clear to people who have been administering MS products for more than three years, but I assure you is not to the rest of us.

What is the Client Object Model?
As far as I am aware, an object model is what you use to describe the construction plans and dependencies for your software. There are twenty links under Microsoft's USING THE CLIENT OBJECT MODEL page, one of which is "Creating Windows Console Managed Client Object Model Applications," none of which are "Open a CMD browser (on relevant machine/on local machine) (screencap) and type "sudo drop (relevant-path)
ARE YOU SURE -p
YES"

Good luck learning things of use on a deadline there.

What is PowerShell?
Microsoft appears to have re-written the command line to include... cmdlets. Also a vast portal on the greatness of PowerShell. Possibly, if you already know PowerShell, or any shell, this will be useful to you. But I have twenty minutes to get rid of a load of drop libraries. This is not useful either.

Sharepoint Manager 201x Looks Dodgy
Doesn't it just! But it's from CodePlex, so it's probably okay. Probably. Be fair, your network is full of zombienets already, and you REALLY need to get rid of those libraries. There are four ditched documents in Education already. They keep e-mailing you. Fail.

Sharepoint Manager is findable in all three flavours, 2007, 2010 and 2013, at http://spm.codeplex.com/.

1. Download Sharepoint Manager.
2. Install it on the computer running the instance of Sharepoint you wish to Manage.
3. Profit! You can find the lists you're looking to edit in the folder browser, and their relevant properties in the right-hand window.
4. Navigate to the relevant site, with the relevant Drop Library.
5. Set the "AllowDeletion" to True
6. Save all changes
7. Return to your local computer from your remote browse window
8. Open your local instance of IE and delete the libraries as normal
9. Feel smug* about the world and knock off for lunch.

*Quietly, beautifully confident that you have just installed a back-end hack full of malware to a sensitive location due to your own incompetence at the field of Developing jack-squat, but even more confident that there are no drop libraries left. Decide this flavour of paranoia counts as a victory. Still knock off for lunch.

Smartphones and Museum Security

This is almost unrelated to Sharepoint, but directly related to management issues within software development. And museums.

I recently acquired a smartphone, one of them new-fangled pocketglass businesses. It is from Google because my friends are hackers and therefore when they hand down phones, they hand down the best phones, flat glass things with changeable batteries made in Korea like fashion will be for the next ten years, and the phones are generally scraped absolutely clean of nonsense. After receiving their phones, I place them in plastic boxes and use them until they are run over by cars.
Number Of Phones Lost To Being Run Over By Cars, Last Three Years: Six.
Suspicion of Value of Phones Generally: Very High.

As an outsider to how systems are supposed to work, this new pocketglass causes me deep-set suspicion.  Every major piece of software I have ever touched has seemed, once I got inside it, hideously broken. I am aware in my bones that things rot. For example, there is almost certainly a botnet in nearly every major museum, all over the world, because as museum staff we just don't have the money to prevent them; bureaucracy, of which proper software security is an evolved form, is hopelessly expensive. Having gone through the wringer of Microsoft's idea of the future, always a relay race of catch-up, I wonder how long it will be until these tiny perfect glasses begin to break. My hacker friends say not long.

There is an interesting problem here: banks tend not to store things that are actually irreplaceable, in the sense that more cannot be printed, but museums sure do. Whatever it is a given museum stores, it is almost certainly not multiple. We don't do multiples. There are no copies of this work. The work is the work and the whole of the work, and though there may be records, scans, and 3D prints of it, once it is gone, it is gone. And museums are almost always going broke, but lately, they are going broker, faster. The things we store are valuable because they are the sort of thing that is not taxed as income, and cannot be easily shared, except, of course, that it can. We hold the cargo cult in our bellies and our basements and our records-keeping. We are no longer truly funding or valuing our own research, but the things we were once researching still need to be preserved, at great cost.

A pocket glass radio that can control everything, including electronic locks, and that talks to other pocket radios by touch. I am wondering what their common cold is going to look like, and what doors it will pop open with its coughing.

The Quicklaunch

The Quicklaunch is the portion of sharepoint popularly known as the Left Nav menu. There is no way to mince words: the left nav is badly written to automate tasks, such that the net result is that said tasks become manual always. Here is a short list of its auto-generated things:

• Automatically generating suckerfish pop-out menus for new lists (everything is a list)
• Automatically changing various links to headings and headings to links
• Automatically nesting things (see above, cockroaches, mice, new pages)

The thing is, you can see the outlines of where this may have been helpful once. Similar to <span> tags all over everything (including this post), it's easy to see where coding has gotten in the way of ideology.*

This Is How The Left Nav Thinks

In Sharepoint 2007, as you flicked back and forth using the quicklaunch, the "level" of the quicklaunch would be set explicitly. This means that if you were on Page A, and a given link was Level 3, and you clicked that link, the link would likely become Level 1 or Level 2 on the inherited site. Depending on how competent the Information Architect was, that level might now display its siblings and parent... or not.

They have slightly sorted this out in Sharepoint 2010, except now, the support for your class inheritances is specified by name in the back end. This is then one o' them "lateral" changes where, like shoving your peas around your plate, something has changed without actually being corrected.

Explicit styling of the various inheritances, laid out in Core.css, will be to blame here - but so too are site definitions and weird automatic navigation and, of course, poorly-managed software development teams that appear to privately hate each other. This is a common problem at Microsoft, and will turn up later when we try to navigate workflows.

The Quicklaunch functions, displays, and generates differently in different Sharepoint site "definitions." Site Definitions** are code that sits on the server to tell sharepoint what to include when you try to generate a new site. At their root, Site Definitions are why you can't have nice things in Team Sites; the definition includes the features list, and someone in Redmond decided Team Sites don't want Group Lists by default. If you were better with C# and cared about this problem at all, you might fix it at root. You are bad at C# and are angry about having to fix it at root at all, so the actual problem here is how to design your information architecture and jQuery to repair the thing without having to touch Sharepoint proper at all.
**Ominous capitalization returns! Any time anyone ominously capitalizes anything, you are In For It. It, here, is A Sloth Of Bears.

So, first things first. Each Subsite is a new level of code. In previous versions of Sharepoint, it would then generate a little tag, like .level1, and you would style that. It worked okay most of the time, although around level 3, it started to get weird. Deprecated! Now things are inheritance-named in a mockery of Web Standards and you need to find out what their names are.

Sharepoint still only supports so many levels of subsite before it begins to get strange, and that level is 3. Level 1 is your home site, http://[YOUR STUPID SERVER:PORT]/. Level 2 is the first // address after that - so http://[YOUR STUPID SERVER:PORT]/Departments or /Office Documents.

That first // can be either a subsite, or a list, or a page. They will all style differently in your side navigation, and will all be the very thorny devil to reproduce elsewhere.

Level 3 is then the next // after level 2. Most of your inheritances, named explicitly, are probably working up to this point, and you are probably safe. The difficulty will come in at Level 4 and below, so... http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html.

Whenever you load http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html, your side navigation will completely lose its shit, even if you have done everything correctly. This is a long bug, caused, as mentioned, by two likely sources. The first is bad initial architecture. You noticed that the calendar bugs can sometimes be solved by naming them one thing, then undoing it, then naming them something else - this is like that. The preferences set when you launch the particular subsite matter.

The trick here is to set all of them, explicitly, to manual management when you create the site. Then you set up each link manually as you go, in Site Settings: Navigation. You can link those things and set them as headers. It is best to not set them as below one another, because then you will be faced with CSS-styling them to not Suckerfish all over the place, and from a pragmatic point of view, it does not matter whether or not they are nested - the headers and key levels will display differently no matter what.

Breaking Down The Quicklaunch CSS

.s4-ql UL.root > LI > .menu-item << this is typically what awaits you.

So. The Quicklaunch styles are nested in class .s4-ql. Inside of that is an unordered list, which is class-named "root." There is a chevron, which affects the nesting level of the LI in question, and which is the subject of much Sturm unt Drang upon the internet WRT correctness in published definitions versus legibility. Mostly, what this means is you can identify particular nests of tags by chevron abuse.

That this almost certainly means your menu is badly written is beside the point. Skip it. It wasn't made by Web People anyway, which, obvs.

Another chevron, and then .menu-item.

The naming structure here is pulled straight out of the existing Microstuff in Core.css. The trick is not writing any of this yourself, because it is to be assumed that you know what you are doing wrt Legible, Semantic Code and never nest tags such that chevrons are required for styling. So! The trick is FINDING these classes and then altering them to begin with. You will probably not have to build your own structures. Even using a standard reset for CSS styling is somewhat questionable before Sharepoint 2013.

Just find the thing marked .s4-(whatever) and style that.

*Do you know about web design ideology? No? Not at all? Pity. You have a long and adventurously boring amount of reading to do, mostly at Happy Cog's source code and A List Apart. Pro Tip: Their source code is almost certainly generated by Rails now.

Subsites Nest. Use As Few As Possible.

Subsites nest. They are like cockroaches or mice in that regard, because if you do not keep a tight eye on them, they can nest limitlessly.

This is handy, because they inherit their permissions from the main site. In theory, you need only permission the main site correctly and away you go; you can let the subsites inherit their permissions, and each one can be used to organize different material. Broadly correct use means you really can do this - finance can have a different sub-site than IT, and they can each be permissioned as separately as necessary. The trouble comes in later, when you meet your clients and become aware of their commitment wholly to bad permission structures. 

Anyone who works with Windows systems is already aware that MS sets permissions funny. Here is the speculation: because MS works with old, well-established teams, each team manages their permissions settings for their software a little differently, and they probably have no core permissioning squad with overreach for all things. So! MS stuff Sets Permissions Funny, and that seems normal until you begin working in a UNIX environment. Sharepoint subsites inherit this tendency, to break permissioning.

The other thing is that subsites under the main site inherit different permissions and different "levels" based on a variety of non-specified variables. The site itself will be fine, but the "level" it is at under the main site will affect how the subsite displays on the quick-launch. The Main site is generally counted as Level 1 (except when it is not, such as while you are in a subsite....) and the created sites are then Level 2+.

The trick here is that the quicklaunch automagically sets whether it is displaying sub-sites or pages or both, and then it gets confusing fast. Folders, in the URL, are sometimes at the same level as subsites, but they are not subsites, so they get tagged differently in front-end navigation. Or at least, they used to do; in Sharepoint 2010, the navigation is on generally shaky ground.

Because of the dodgy navigation issues, and how difficult it is to prevent Folder and Permission Nesting, it is for the best to limit the depth of subsites you support to one or two at most. At level 3, the quicklaunch becomes deeply strange, and at level 4 you basically have to rewrite everything because it ceases to inherit properly. 

Best Practices So Far:

1. No folders, ever, unless you REALLY need them for permissioning a document set with shared metadata.
2. Depth of no more than 3 subsites. Here is how your quicklaunch will come to look otherwise:
1. Main Site
1. Departments
1. Finance
2. IT
3. Collectables
1. This is all good
2. Hey no problem
3. Wait hang on something's dodgy here
4. Hey what's this door
5. AAUAUAUAGUGH GIVE ME BACK MY LEG
1. *smear of blood, something about minotaurs*
2. Projects
1. This needs collaboration
2. Everything is totally chill!
3. Man, this is such a convenient document sharing technology
4. I wonder where Rachel McPropellerGallery got to?
5. She was always so cool.

Why Is Sharepoint So Broken, Anyway? A History Lesson.

So why is it that nothing in Sharepoint quite works, even when you undo it later, or fix it, or it should be fixed but is not? Simple: there are handshakes missing all over the place. Parts of Sharepoint just do not talk to other parts. This is not part of the planned functionality of the thing, I mean, probably someone at MS really cares about the technology. It does work well in some very small, key ways.

The overall terribleness, though, is an extended part of what we call a Corporate Culture Problem. The problem is that, really, Microsoft is a risk-averse company with a risk-averse history working in an incredibly risk-forward industry, and it has not learned to hedge its bets in any sort of correct fashion. Microsoft has been late to the party while simultaneously refusing the party's best lessons for years now, then trying to make up its homework by copying the substantially better work of its peers.

The reason for this is simple: Microsoft lost all its corporate caché in the late 1990s, just as the first run of the webkids was leaving school. We'd land in the teeth of both the web crash and the recession, later, and in the meantime, although MS attracted Coupland - and therefore Gen X - it lost out on the much larger boom of the baby boomer's kids. It did this by developing a corporate strategy based entirely on disconnected systems and computer security, rather than openness, sharing, and peer review. The much larger generation of Web Kids learn by doing, mostly, because MS made its systems locked and university seemed expensive but the web itself has always been accessible. We are mostly self-taught - and likely to become moreso, as enrolment in CS programs drops.

They jumped too soon, and Sharepoint sucks because it is sharing software manufactured by a company that does not like to share at all, in any way, at any level. You can see this in the DNA of the software: there are errors, frequent ones, caused by what appears to be nothing more than bad team management. Everything is driven from the back end, in ways that once might have been good, but are no longer good, because they are not actually well-organized; organization is a function of sharing. They are dependent on assumptions and libraries that have to do with basic Windows architecture... which stops working the moment you recognize that the internet is an inherently unstable system.

But how can this BE, you ask, you who has paid good money for this system, and trusted the corporation selling it to you?

1. Sharepoint is built on seven separate base technologies, all of them huge, most of them legacy spare parts that have been dolled up like a late-run K-car and re-sold.
2. The dolling of these parts has not been well-managed, due to Sharepoint being, in large part, nothing but a weird profit centre for a long time. 
3. This has long historic roots. Microsoft fucked up at the internet way, way back - back when they were first getting into it - and have been engaged in playing catch-up as the fat kid ever since. 
4. They chased Dreamweaver with Frontpage, which became Sharepoint Designer after a rebranding.
5. Dreamweaver was terrible to begin with.
6. They missed Search and tried stealing Google's results for a while
7. Now they're stealing Apple's store design, and tablet design.
8. This is because Microsoft is a relatively old company, with a long legacy, working in an industry that is moving incredibly quickly. Their history is one of business software and risk-aversion, but they cannot make money without selling a new thing. 
9. Additionally, they are controlled by people who are uncomfortable with risk, presently unsure of  their core business, and worried about shareholder value rather than product quality.
1. This has to do with their age, which has to do with Nuclear War and The Boomers Have All The Money being a thing they were actually threatened with, where our age is still arriving, and is - see also Fiscal Cliff - likely to be more janitorial in its disasters. Cleanup in Aisle Twelve.
10. Their decisions are therefore being driven by marketing, rather than by actual use.
11. Because the company is not, even now, quite sure what the fuck the internet is for.
12. Which means that they are dedicated to selling their products to people who are afraid of the cloud
13. Want something shiny for their cash if they are going to hand it over
14. Who believe in Security
15. But are not able to grasp what in practice that means
16. And they are saddled with the buggiest, most hackable operating system and most difficult consumer-grade software because that used to be how you made money. 
17. No-one is sure how you make money now, but Brushed Aluminum and Shit Doing What It Says On The Packet is working out pretty well for most of them.
18. This scares Microsoft because, having missed out on the web, and utterly lacking any interesting technology except perhaps the xBox, where they continue to haul defeat from the jaws of victory, they are failing. Very, very slowly. You can fail for a long time before your company dies. You can make a lot of money failing, and take a lot of people with you.
19. Welcome to the life cycle of the American corporation, where, as we all know, money for shareholders is more important than people.

Unfortunately, unlike candy [Hershey's] , or beer [AB InBev], both of which are luxuries that can be put aside, the Microsoft problem has a direct consequence on the architecture of business operations in pretty well every English-speaking country. The maintenance of this software is boring, but necessary, as driven as it is by selling rather than making something worth using, and as important as it is to major corporations with a great deal of money running through them.

This is really pretty stupid, all of it, because it is like having two filing cabinet companies, and one of them simply has broken locks on everything. There is no end in sight, but the first filing cabinet company to do it better - thus far, Google - will have a mighty prize. It is already turning up in Android phones, alongside the new malware marketplace.

Unfortunately, twice, is that Google is now publicly traded, and is interested in documenting every last bleeding thing you do. It is very probably not long before this style of problem expands; how should a company be?