Skip to main content

Welcome, and sharing some points

Welcome to Geek In The Pink, a blog dedicated to all of my I.T. musings worthy of publishing to the world ("worthy" may be an overstatement, but that's for you to decide, right?)

My intention is to cover any subject that directly or indirectly relates to the I.T. industry, particularly in Australia, but also the world. I work with a number of diverse technologies, both paid for and volunteering, so content will vary over time. There may also be a small amount of political opinion, however I intend to keep that to a minimum.

So, this first post is a short one, and really just some commentary instead of some real-life tangible information. Today I'm working with Microsoft SharePoint master pages, and themes. These are what you need to work with in order to change the look and feel of a SharePoint site. Basically, it boils down to:
  • SharePoint Themes are used to define CSS and supporting graphic files
  • SharePoint Master pages, like ASP.NET Master pages, are used to define a consistent HTML structure for your site
In reality, SharePoint is nothing more than an ASP.NET web application. If you come from an ASP.NET development background, Themes and Master pages are a concept you are probably familiar with. When you build an ASPX file, the <%@Page %> directive can include attributes to define both of these.

When it comes to themes, the trick with SharePoint sites, however, is that the HTML has a whole lot of pre-defined CSS named elements, mostly via class attributes. Also, in typical Microsoft fashion, the HTML is not CSS friendly. Instead of separating the content from design, Microsoft have stuck with their table-based layouts, and multiple HTML entities identified by the same CSS names, in a way that makes sense if you're building the HTML and CSS together as one process, but does not make sense when you're attempting to re-skin an existing website.

The result is a cludgey, hacky CSS definition that is not easily readable or maintainable.

I'm going to wonder out-loud for a moment: Does Microsoft have any plans to fix this?

One of the key benefits I've noticed lately with the onset of "Web 2.0" style site development, is there's a clear push to implement a proper CSS - HTML / design - content separation. ASP.NET, and as a result, SharePoint, do not lead a developer down this path with the current out-of-the-box web controls.

One major block that is preventing SharePoint being accepted as a viable publishing mechanism for public-facing websites, is the intrinsic hooks to MSIE.

A cursory look over a typical page served up by SharePoint, and we have an example: <ie:menuitem> tags do not belong in the HTML of a public site. What's more, there are perfectly valid, standards compliant, backward compatible methods to acheive the results that those tags set out to accomplish. Microsoft need to conform, in order for their products to be taken seriously outside the internal, enterprise market.

By the way, as you may have noticed, this post is largely about SharePoint. To give you an idea of other near-future topics: Apple Dashboard widget development, PHP site development, volunteer web development work, and MS SQL Reporting Services.


  1. Mental note to self: When editing master pages in the master page gallery, try to avoid checking in a version of the page that doesn't have all the required Placeholder elements. Doing so renders the master page useless, and any site using that master page ends up with the infamous "Unknown error" page.


Post a Comment

Popular posts from this blog

Thoughts, shortcomings, gotchas on SPFx Dynamic Data capabilities

It's the festive break, and I thought I'd try the new Dynamic Data capabilities that recently went to General Availability in SharePoint Framework 1.7.

I've been building a lot of React components lately, and all the SPFx web parts and application customisers with visual elements we create at Engage Squared, are built on React.  Dynamic Data in SPFx introduces a whole new world of modularity that we haven't had before. We can now split up the page elements into multiple web parts that, in the past, have been combined as one web part so state can be passed between them.  Doing this gives control back to the page author, with the ability to position components how they wish.

Breaking components up in to individual web parts also changes the way the components are designed, and forces the developer to leverage the responsive capabilities of modern pages.  Modern pages are designed from the ground up to work on many different screen sizes, and as long as each individual co…

Apps for SharePoint 2013 - Client and Server-side code

It's about time I blew the dust off this blog. Tonight I did a presentation at the Melbourne SharePoint User Group entitled Apps For SharePoint (2013). It included two demos based on the App For SharePoint 2013 solution template in Visual Studio 2012.

The two demos illustrated how you can create a separate ASP.Net Web Application. Demo 1 showed how easy it is to hook in to SharePoint to obtain List properties via server-side code (populating an ASP.Net Repeater Control). Demo 2 showed what you can do with SharePoint 2013's Javascript hooks. Specifically, using SP.UI.Controls.js from the /_layouts/15/ SharePoint folder to pull chrome elements out of SharePoint, and render them in your ASP.Net web app.

No animals were harmed in the making of these demos, but a few articles kindly provided on the Microsoft MSDN site helped put it together:
How to: Set up an on-premises development environment for apps for SharePointHow to: Create high-trust apps for SharePoint 2013 using the se…

SharePoint "Like" button

Ever wondered what the users of your Intranet really like or don't like? Ever wanted your SharePoint 2007 site to be more "web 2.0"-ey? Well I've published this quick and dirty codeplex project that allows the addition of a "Like" button the any SharePoint List item page.
The project is available as a WSP, and source code.
It consists of two things - a Web Part that is the button that users click to "Like" or "Unlike" something, and a List Template that can be used to create a list to store who "Likes" an item.
The button has two ways of operating. If it finds a list that was built on the List Template included in the WSP, it allows each user to Like or Unlike an item as they see fit. The button uses the List it found to keep track of who likes a given item, and queries the list when it renders to determine which option should be presented. Along with the button, the web part also displays a brief message explaining how many pe…