Problem with jQuery 1.7+ and SPServices

<UPDATE dateTime=”2012-12-04″>

This issue is resolved in v0.7.0+. See this post for more details, including the SPFilterNode function. </UPDATE>

<UPDATE dateTime=”2011-11-15T11:59GMT-1″>

Steve Workman has come up with a much improved way to do the selecting for things like z:row in general – it’s much faster, as Steve’s statistics show – and it also works with jQuery 1.7. I’ve added it to the latest alpha for v1.6.3 (which I will probably rename v0.7.0). More details to come, but this issue is going to be resolved in the upcoming release of SPServices.

</UPDATE>

Alert reader Dustin Meany pinged me yesterday with a brief email through this blog:

http://bugs.jquery.com/ticket/10377 — I think you should update the documentation for SPServices…

Ah, if the issue were only as small as his email. The ticket on the jQuery site talks about the fact that the notation that I’ve been recommending to parse through the results of a call to the Web Services, like:

$(xData.responseXML).find("[nodeName='z:row']").each(function() {
  // Do something
});

is no longer valid in jQuery 1.7.

I’ve confirmed in my main test pages that jQuery 1.7 no longer matches on any z:rows in calls to GetListItems. That breaks the majority of the “value added” functions in SPServices. The [nodeName='z:row'] notation has proved highly useful to ensure cross-browser compatibility, and that was the reason I’ve been recommending it in the first place. Because GetListItems uses the somewhat odd namespace of z:row, not all browsers react the same way. Of course GetListItems is the single most used Web Service operation with SPServices. Most of the other operations, which are used less often, do not use this type of namespace.

So the question is how we as a development community handle this. Based on the suggestion in the jQuery ticket, I could implement a function in SPServices itself that probably will solve the issues for the SPServices value-added functions. There are only ten calls in SPServices at the moment that use the [nodeName='z:row'] notation. However, there are thousands of you out there who have your own custom scripts written on top of SPServices that will break if you move to jQuery 1.7+.

The suggestion of switching to the .find("z\\:row, row") notation may work. I’ve quickly tested it with IE9, Chrome 15, Safari 5.1, and Firefox 7.0, all on my Windows 7 laptop. I don’t trust my cursory test, of course; there’s more work to do.

I hold no sway over the jQuery development team. They make their decisions without any knowledge of my little SPServices library or probably even SharePoint.

This, along with the XSL timeout issue I wrote about yesterday, may prove to be a big blow to those of us who choose to develop in SharePoint’s Middle Tier. As the standard bearer for this little movement, I can only do so much to make noise about how important and useful these development techniques are. When these types of roadblocks are put up, there’s little I can do to change things.

Namespacing CSS Classes and IDs in Your SharePoint Branding

A graphical depiction of a very simple css doc...

Image via Wikipedia

This is a concept I’ve gone back and forth on over the last year or so. I think I’m ready to firmly come down on the “Yes, let’s do it” side of the argument.

Here’s the first definition of namespace from Wikipedia:

In general, a namespace is a container that provides context for the identifiers (names, or technical terms, or words) it holds, and allows the disambiguation of homonym identifiers residing in different namespaces.

Now, for you normal people out there, what that *usually* means is prefixing the names of something with a consistent value to help you assort things into groups. With most modern programming languages, you benefit from namespaces because it assures you that your code won’t stomp on anyone else’s. (At least it’s far less likely, as someone else can, of course, choose the same namespace.)

In my SPServices library, every single function resides in the SPServices namespace. That means that all the function names start with SPServices [dot]:

You get the idea.

Even though my function names are most likely going to be unique – I’ve chosen rather long, descriptive function names on purpose – it’s possible that someone else could have a function of the same name. By putting all the functions into the SPServices namespace, I’ve reduced the possibility of function name “collisions” to almost nil.

But what does all of this have to do with CSS, you are probably wondering? Well in CSS, you can do essentially the same thing. Let’s say you are working on a project for Foo, Inc. with SharePoint. If you precede all of your custom CSS classes for Foo, Inc. with something like “foo-“, then you have reduced the possibility that there might be an existing CSS class with that name. You can do the same thing with unique ids for elements in your markup:

When we brand SharePoint, we’re building on top of an existing platform. If we were starting with a green field, we wouldn’t need to worry about CSS class collisions; we’d be able to pick and old naming that we wanted.  As an example, there is a class used in one of the out of the box Web Parts (I can’t recall exactly which one, but I think it may be the Summary Links Web Part) called “footer”. That’s a very garden variety name, and one that we might be tempted to create ourselves to style a page footer. As soon as we do, though, any of the Web Parts which have that class applied to it inherit whatever styling we’ve applied to our own footer class. I know for a fact that this can be a problem because I had to track it down more than once.

A safer class name would be “foo-footer”. It’s almost guaranteed to be unique, and we won’t stomp on an existing class named footer. This is a good approach overall. If you see a class which has a name starting with “foo-“, you know that it is specific to this client or application or branding scheme; whatever you’d like the namespace to indicate.

Microsoft does the namespacing thing pretty badly. Some of the out of the box CSS classes for SharePoint start with “ms-“; some don’t. Some classes start with a prefix which indicates something about the functionality in which they are used, like “srch-Icon” for a search icon or “UserCaption” for a caption for some user info. In SharePoint 2010, it got more complicated, as some classes start with “s4-” (one supposes that this means SharePoint 4.0, which is the internal version for SharePoint 2010 – it’s the fourth version of SharePoint) and some don’t. There doesn’t seem to be any real rhyme or reason to it other than the fact that different development teams thought about CSS classes differently. Take a look through core.css (SharePoint 2007) or corev4.css (SharePoint 2010) sometime and see if you can make heads or tails of it; I certainly can’t see much pattern in there. (Don’t even get me started on the whole inline vs. separately stored CSS issue. That’s a different smelly can of worms.)

Add to the out of the box CSS classes those which your developers are likely to embed in user controls, rendering templates, and the like, and there is even more possibility for a mess. To me, this is a clear indication of the fact that .NET’s abstractions teach developers, even Microsoft ones, not to think too much about what happens in the browser. They are told to use the .NET abstractions and all will be well when the functionality finally gets in front of the user. Well, not so much, and not so often.

When I see an abundant use of the !important tag in CSS (which I consider just plain evil), it is usually either due to the CSS creators novice use of selectors or due to a lack of namespacing. (If you find yourself wanting to use !important, think long and hard about why. It should be a very unusual exception, not the rule.) Another benefit of using the namespace approach is that you’ll have unique class names and won’t need to fight with the out-of-the-box styling, at least not as much.

Of course, there must be a downside to all of this, you probably are thinking. There are a few drawbacks, surely, but I think the benefits outweigh them. You’ll type a little bit more when you develop and apply your CSS, but I think that’s really the biggest cost. There will also be a few more characters going over the wire, but bandwidth gets better all the time. (If you’re still on a modem connection, then by all means, feel free to ignore this advice.)  All in all, this approach is just a good idea with little overhead.