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
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.
No comments:
Post a Comment