Rules to Better SharePoint Development

Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see. ​

If you still need help, visit SharePoint Server ​Consulting​ and book in a consultant.​​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
Do you agree with them all? Are we missing some? Let us know what you think.
  1. Are your Developers Managing your Projects with TFS (with proven Agile/Scrum and ALM Strategies)?

    Team Foundation Server is the fully integrated solution to manage projects, giving developers, testers and management a single source of truth for all project needs.

    Project Managers and stakeholders will love:

    • TFS's integration with code/SQL/SharePoint which provides a dashboard with project reports, giving them greater visibility of the project status and burn down lists
    • The easily customization of the data using Excel Web Services

    Developers will love:

    • TFS 2010 for the SQL and SharePoint Server Explorer and the integration of viewing, creating and deploying
    • That they don't have to try to interpret a bug report from a tester, and then they have to reproduce it. Why? Because of Intellitrace, which allows you to double click and open to the exact line of code with the variables set.
    • Seamless source control
    • No waiting for compiling and tests to run. The integration with the build server (continuous integration) is the biggest productivity boost you can give a developer
    • SharePoint Wiki

    Testers will love:

    • The many ways of automating their manual tests via:
      • Web tests
      • Performance tests
      • And the jewel in the crown, Coded UI Tests
    • The fact they never have to spend time reproducing a bug before documenting it
    • And it gets better, they don't have to document it because testing tools recorded what they did
    • Later on, when they decide to go with Lab Manager they will never spend time setting up that special environment (say running windows 95 and IE6)

    Managing your SharePoint Projects with TFS (with proven Agile/Scrum and ALM Strategies)

  2. ASP.NET vs SharePoint development - do you know deployment is different?

    In ASP.NET deployment is a simple xcopy. Or you can right click the Web Site project and  "Publish Web Site" in Visual Studio.

    Fugure: Publish Web Site in Visual Studio


    In SharePoint the way to deploy a set of changes is via a solution package.

    SharePoint provides additional layer and infrastructure on top of ASP.NET  - part of this layer is the support for administrators (who may not be developers) to quickly add, remove, activate and deactivate features across a SharePoint site farm.

    These are awesome features and something that basic ASP.NET does not have, but it does add additional development overhead to build the solution packaging.

    1. You need to create such a package via VSeWSS (or a similar tool such as WSP Builder)
    2. Add entries for all the files you want to include in the package
    3. Update and get the latest version of the files from development SharePoint or TFS
    4. Compile the package into a WSP file (which is a cab file)
    5. Test the package on a staging server.
    6. Deploy it on a production server.
  3. ASP.NET vs SharePoint development - do you know source control is different?

    In ASP.NET
    Typically, the team will store the code on a source control system such as TFS (Team Foundation Server), check it out to their own local system, develop and test locally then check it back into source control for sharing.

    In SharePoint
    SharePoint comes with its own document control and version history out of the box. This is great for collaborating between developers and designers, but isn’t available for everything.

    Unlike TFS, SharePoint does not support multiple check-out so each file can only be checked out to one person at a time.  The modification must be checked back into SharePoint.

    We think the following are best tracked on a development SharePoint server:

    • Master page
    • Page Layouts
    • XSL
    • CSS

    And these should not (or cannot) be version controlled on SharePoint server:

    • Low level customizations such as custom web parts should still be developed in VS.NET and stored in TFS.
    • Package files to build solution packages should be stored in TFS.
  4. Do you always set InfoPath compatibility mode to design for both Rich and Web client forms?

    ​This is the number one, and most important rule in working with InfoPath.

    Always go for the lowest common denominator.  It sure beats realizing half way later that your form can't be hosted on SharePoint InfoPath Forms Services!

  5. Do you always use Data Connection Library for InfoPath forms?

    SharePoint allows you to create a Data Connection Library to hold all the connection information that Forms and Excel services can utilize.

    You should always use a Data Connection Library.

    Data Connection Library provides a central location for defining all the connections to various data sources within your company.

    • It allows you to change the data source definition in one place, without having to worry about changing the same definition in 50 forms and excel spreadsheets.
    • A centralized data connection library also helps your users to locate data easily.
    • Your users don't want to know the intricate details on how to get a particular data - they just want the data and have the form working!  So if you as the administrator provides it for them, they will love you, they will use it, and you will have an easier time managing your SharePoint site!​
    Everyone wins!
  6. Do you create a minimal master page?

    To create a master page or reuse an existing master page is a time-consuming process. Because you have to determine what the Office SharePoint Server 2007 page model requires — necessary content placeholders and controls to work with the page layouts.

    Another problem of Default.master is that it contains many tables that are difficult to style.
    <%@Master language="C#"%>

    <br><asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/><br>







    Bad example - using default master page

    So we recommend using the minimal master page which includes the necessary placeholders.
    To create a minimal master page

    1. Open SharePoint Designer.
    2. On the File menu, click New, point to SharePoint Content, and then click the Page tab.
    3. Double-click Master Page to create a new master page.
    4. Click Design to show the master page in design view. You should see header and left margin areas and several content placeholders in the master page.
    5. Click Code to show the master page in code view.
    6. Copy the code into the master page
      SharePoint 2007 -
      SharePoint 2010 - ​273.aspx
      <%@ Master language="C#" %>

                  <br>                <asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" /><br>           




          Good example - using minimal master page
    7. On the File menu, click Save As, provide a unique file name with the .master extension, and then save the file to the master page gallery (/_catalogs/masterpage) in your site collection.
  7. Do you know common web configuration stuff you will need?

     In SharePoint, web configuration includes:
    1. ASP.NET 3.5/4.0 library references – this is necessary for all the ASP.NET AJAX calls
    2. Add system.web/pages/controls – to add additional tag prefix from System.W eb.Extensions
    3. Add HttpModule (for example – to clean up extra JavaScript from SharePoint)
    4. SafeControl tags for all custom dlls – in general these can be added via your solution package as well

    You should always use a SPConfigModification class to modify your web.config – never tell your user or administrator to make changes manually!  This also allows them to switch off a feature from SharePoint knowing that the changes had been reverted.

    For developers – you must test your SPConfigModification carefully, mismatched XPath will cause problems in your web.config and create duplicate entries!
  8. Do you know the ASP.NET skills that do not translate (aka different) ?

    ASP.NET is file system driven, SharePoint is database driven – all SharePoint content and meta data comes from a database, include images, HTML, Master Page, etc. SharePoint provides a framework where components can be plugged in, and out of the box these areas are improved:

    • Security model, membership, permissions
    • There’s a relatively consistent UI framework
    • Menus, navigation and site maps
    • Administration of access, site owners can change permissions for that site – without admins

    Deployment model is very different:

    • ASP.NET has MSI file or XCopy deployment – individual server
    • SharePoint deployment is via Solution Package – but goes cross site farms
    • Deployment is both declarative in XML format, as well as in code with Feature and Event receivers


    • ASP.NET is mostly done in Visual Studio .NET
    • SharePoint development is split among:
      • Internet Explorer – SharePoint configurations (note: non IE browsers remain 2nd level and isn’t as good as IE with SharePoint)
      • Microsoft SharePoint Designer – SharePoint HTML page design and customization
      • Visual Studio .NET – custom web parts, custom workflows, solution packages
  9. Do you know to *never* touch a production environment with SharePoint designer?

    • SharePoint designer can silently reformat your code and introduce errors.
    • If you modify any master page or page layout file with SharePoint designer, it becomes customized. This means that SharePoint is now looking at a customized version stored in the database rather than the version on the file system. You then can't deploy future changes, because SharePoint will now always serve the customized version instead of the ghosted version in the solution package.
  10. Do you know that developers should do all their custom work in their own SharePoint development environment?

    This is to prevent their work affecting other developers. During development, you can expect many of these things to happen:
    • IIS resets may need to be done frequently, which stops the SharePoint website working.
    • Custom web parts can easily introduce memory leaks which can stop SharePoint working.
    • You may be running development SharePoint in debugging mode which would hold the server thread.
    • You may be reading event or error logs that are being polluted by other developers simultaneously.

    Thus, all SharePoint customization and development must be done on a Virtual Machine. No ifs, no buts.

    1. It's very important to correctly setup a SharePoint environment for development. Correctly configured, this will save you a lot of trouble later on.
    2. From time to time, you can seriously screw/damage a SharePoint installation during development and it is best not to install SharePoint on your day-to-day machine.
    3. Additionally, when you start a new SharePoint project you don't want to carry all the baggage from previous customizations that could potentially affect your new project.​

    There are many other benefits of using a virtual machine for development

    1. Virtual machines can be fired up and shut down easily
    2. Virtual machines can run faster, via being located on a different server and thus it doesn't waste developers' own computer resources
    3. Virtual machines can be copied and brought to a client for demonstration or testing
    4. They are the best way to quickly test or experiment with something new
    5. Virtual machines can frees up resources on the host, so it doesn’t waste resource when developers are not working on SharePoint
    6. Virtual machines can be easily cloned to scale up the development team
    7. Virtual machines enable developers to work in Windows Server 2003 / 2008 environment so they will be aware of the configuration issue when deploying to staging and production

    There are few considerations when using Virtual Machines:

    1. Need to activate additional servers
    2. Need at least 2 GB of RAM for SharePoint 2007
    3. Need at least 4 GB of RAM for SharePoint 2010
    4. Virtual PC does not support 64 bit Operating Systems 
      • If you’re using Windows 7 or Vista, we recommend using ‘boot to VHD’ or VMWare

    If you are after a clean, pre-configured SharePoint server image to test SharePoint, the easiest way is to download a trial ​VM from Microsoft

    Tip: More info on setting up SharePoint VM
  11. Do you know the ASP.NET skills that translate?

    Microsoft SharePoint Technologies is built on top of ASP.NET technologies.  In particular, MOSS 2007 is based on ASP.NET 2.0, SharePoint 2010 is based on ASP.NET 3.5, SharePoint 2013 is based on ASP.NET 4.​

    This means that there are many skills that an ASP.NET developer already has that can be translated to SharePoint directly.

    • Master Pages – SharePoint uses master pages
    • Site Map – SharePoint uses the ASP.NET site map provider model and comes with many additional customized site map providers out of the box
    • Menu – SharePoint uses ASP.NET menu controls, powered by site maps
    • Page Control Lifecycle – the same key fundamental knowledge for ASP.NET is also necessary when making custom SharePoint development
    • Web.Config – like ASP.NET – many SharePoint configuration is done in the Web.Config – though SharePoint provides web UI to modify many of these options from Central Administration
    • .NET – Your .NET skills are definitely not going to go away
    • IIS – Each SharePoint web application is a “Site” in IIS, the site bindings are also identical
  12. Do you know the best ways to deploy a SharePoint solution?

    Development for a SharePoint solution is always risky and may involve bringing down the server from time to time.  So we always customize and develop SharePoint solutions on a separate development server.  But when your development is done, do you know how to deploy your changes to the staging and eventually the production server?

    The Bad method
    The naïve and bad method would be to just back up the entire content database, then copy the database backup to the destination server, and restore it there.

    1. Backup command:
      stsadm –o backup –url http://servername:port -filename c:\myfile.bak
    2. Restore command:
      stsadm –o restore –url http://servername:port –filename c:\myfile.bak -overwrite

    There are quite a few issues with this approach:

    1. At a glance – seems simple
    2. Any additional content at the destination server is wiped out – no content editing can continue while the development work is happening…
    3. Backup file can be extremely large as it includes version history and a lot of extra fat, the file can easily be over a few hundred megabytes!
    4. Deployment via backup and restore is not a Microsoft supported operation

    The Good method
    The better method is to build a feature or solution deployment package

    1. Build a VSeWSS project for package and deployment
    2. When built, this will produce a wsp file (this is a cab file) that can be deployed as features on the destination server

    A few considerations for this approach: 

    1. Site definitions, list definitions, layouts and masterpages, static content and webparts can all be deployed this way
    2. User content cannot be deployed this way. Any content will need to be exported and re-imported to move between development, staging and/or production servers.
  13. Do you make small incremental changes to your VSeWSS projects?

    • When working on packaging SharePoint artefacts into Features & Solutions, you should always make small incremental changes to your VSeWSS projects. Each time you should build & deploy to check you haven't broken anything.
    • You should regularly make labels in TFS so you can quickly compare your changes against previous working versions to identify problems.
  14. Do you know to do data you need CAML?

    CAML is the XML definition for all things in SharePoint, in deployment, and in creating templates, CAML is the only format.

    In SharePoint development, you will also need to know CAML, in particular, how to write a query in CAML.

    •  Widely used in Content Query Web Parts
    • Also used in SharePoint content reports
    • In code, used by SPSiteDataQuery object



    Figure: Example of CAML query 

    You can see - CAML is essentially the same as SQL WHERE syntax, but wrapped in an XML format.

    Problems with CAML:

    1. CAML is XML and is case sensitive – including attributes names. 

      name="Status" />

      ="Status" />

           Figure: Example of CAML query 
    2. SharePoint is not good at telling you if you made a mistake with your CAML query.
           Figure: Debug error message
    3. Hard to debug.
      Tips: Use 3rd Party tools - U2U CAML Query Builder
           Figure: U2U CAML Query Builder
           Note: U2U CAML Builder is the best tool that we have. There are some occasional UI and interface issues, but for creating CAML and testing it against live SharePoint lists it gets the job done. And it’s FREE!



  15. Do you have a version page for your SharePoint site?

    Each time you deploy a new package to your SharePoint site, you should add a new entry in the version list.

    This will enable you to quickly find out which version of the package your SharePoint site is using, and let users know what version they are running.


    • A custom list for Version should be created at the root level of a SharePoint site collection, and each time a package is deployed - a new record should be added to this version list.
    • A simple blank page with a Content Query Web Part can display this versions list in a friendly manner.
    • We do not change the version numbers in the .NET Assembly because the assemblies have to be strong-name signed and deployed to the GAC.  So having a versions list is crucial in working out what version of your package is deployed on which server.
  16. Do you know to try to use the Content Query Web Part (CQWP) over the Data View Web Part (DVWP)?

    These controls are similar, but the DVWP needs heavier customization and should be avoided where possible.

    The CQWP is easier to style. The DVWP should only be used if you need one of these features:

    1. You only want to search on one column in the list, rather than all the (indexed) columns.
    2. You want to perform a search on multiple lists, but not all the lists on a web.
    3. You want to have a very specific Look and Feel that the search results use.
  17. Do you know what is broken in workflow?

    SharePoint comes with some very basic workflows out of the box.  A particular example is the content approval workflow.

    When a content approval workflow is used, it modifies the process of publishing content to be:

    1. User clicks publish (click 1)
    2. Workflow starts, and asks the user to request for approval, there’s an option to add additional messages (click 2)
    3. The workflow sends an email to the user to tell him an approval workflow has started. (email 1)
    4. The workflow also sends an email to the approver(s) (email 2)
    5. The approver receives an email, then returns to the page – they can Approve or Reject the workflow. (click 3)
    6. Either way, a new workflow screen appears, with an option to add additional messages, the approver clicks accept (click 4)
    7. The approval workflow completes and publishes the page. 
    8. It then sends an email telling the user that an approval workflow has been completed (email 3).

    What is the problem?

    The out of the box workflow is extremely generic.  It has no customizations or shortcuts.  Even if you are an approver, you cannot skip any of the steps.  The end result is that you will have to click 4 times and receive 3 emails, for approving your own finalized content.

    These kind of workflows are designed generic to fit any business’ needs – and in fact, businesses using these out of the box workflows have to adjust their staff’s workflow to match SharePoint’s ones.  Which can be counter intuitive.

    We think these SharePoint workflows need to be far more customizable.  

    SharePoint does not provide support for complex reusable workflows easily - most companies go for a 3rd party solution:

    Figure: 3rd party tool - Blackpearl
    Figure: 3rd party tool - Nintex
  18. Do you use SharePoint designer well?

    We love SharePoint designer and use it everyday. 

    But there are things that it doesn't do naturally, or it does really badly.  Here are some tips on using SharePoint designer well.

    • Don't use inline CSS - this goes for any website.
    • Always put
      wrappers around SharePoint controls. This allows us to define styles for SharePoint controls. It is possible to use CssClass like ASP.NET, but then we lose control to SharePoint regarding how that control will be rendered.  Also, some SharePoint controls will eat up your CssClass and not render anything.
    • Naming convention for control id! Don't get lazy.
    • Turn off Auto indent.  Otherwise SharePoint designer will keep modifying your file whenever it saves the HTML - this will make you very upset.


    Uncheck Auto indent
  19. Do you always use Site Columns instead of List Columns?

    A site column is created on a site level and visible to all lists and content types within that site (and subsites).

    You should always try to use Site Columns instead of List Columns

    • New in WSS v3 (SharePoint 2007)
    • The same column can be added to different Content Types, lists, list templates
    • Allows you to make modifications at one place and SharePoint can apply the changes for you across the different lists and content types (doesn't try to fix the content for you though)
    • More visibility of the customization we are applying to the SharePoint website
    • Make sure the site column is added to our own group description such as "SSW Columns" - this is important for filtering and exporting site column customizations for deployment.  Also great because they are now grouped in the UI.
    Figure: Create column - Bad Example
    Figure: Add from existing site columns - Good Example
    Figure: Site Columns - Good Example



    Sometimes you still may want to use a List Column.

    • You are Mary and want to create a simple list to track supplies, but you do not have site permissions to create site columns
  20. Do you know when to use CAML instead of object model?

    SharePoint utilizes CAML to do a lot of things - one of these is using CAML to define a query language to select elements from lists within SharePoint.

    The development experience with CAML is not good.  CAML is unforgiving when it comes to errors, but it doesn't tell you what's wrong.  Thus earning it a bad name with SharePoint developers.  People don't like CAML.

    The SharePoint object model is very comprehensive and lets you select items from lists, select lists from sites, in site-collections within web-applications.

    Naturally, using the object model is great for traversing all elements in a list.  Once you have a handle to the item, you can also easily modify that item.

    On the other hand, one of the SharePoint class SPSiteDataQuery allows a developer to use CAML to specify a query condition that SharePoint can understand to search and return matching elements from across the entire site collection.

    This is the underlying class that the Content Query Web Part relies on.

    So, you need to use object model when you want to:

    • Iterate all elements in a list
    • Modify elements in a list

    And you use CAML, whether in CQWP or in code with SPSiteDataQuery to:

    • Select, filter elements from SharePoint lists
    • Select elements from multiple lists
  21. Do you know when to use SmartPart or WebPart?

    SmartPart is basically a simple but genius idea - it is a simple web part that can host a user control (ascx) inside it via the Page.LoadControl method. That way, all you have to do as a SharePoint developer is to write the ascx control, and you can do it with the Visual Studio designer to arrange the user control via drag and drop, and then when you want the web part on a SharePoint page, you load the generic SmartPart, and tell it to load the ascx that you want.

    However, there are some PRO's and CON's when you use a SmartPart:


    1. Being able to rapidly create the control's layout and then focus on the code behind - in familiar ASP.NET user control style.


    1. Many users switch to full trust for their User Controls and disregard SharePoint security this is very easy to set up, but very bad practice.  The user control dll should be deployed to the GAC.
    2. Performance is not as good as a web part because a SmartPart is "host" by a page.
    3. Hard to deploy - this is a major problem for SSW because we use solution package to deploy web parts.  The ascx can be deployed manually to wss\VirtualDirectories\, or it can be deployed to the 12 hive via _controlTemplates/ - and then the user control referenced via ~/_layouts/controlTemplates/ but this is not an intended feature of SharePoint deployment.
    4. Hard to debug - if the ascx is written with src codebehind, then that file is compiled on demand by ASP.NET you can't debug it easily.  See xxx (link) on how to debug SharePoint.


    Our recommendation:

    1. Understand the difference between SmartParts and Web Parts - don't use SmartParts just because it's "easy" - there are many issues that will come back and hurt the developer.
    2. If your control does not work with SharePoint directly, or has a lot of layout elements it is OK to use SmartParts
    3. Otherwise, write your own Web Part.
  22. Does your SharePoint site have a favicon?

    ​All websites should be following the favicon rule.

    A Favicon is a small image file included on nearly all professional developed sites. When a browser hits your web site and a user bookmarks that site then the favicon.ico graphic will be displayed in the browser’s URL/address line upon subsequent visits to that site.

    Let's see how it's done for SharePoint:


    Figure: One line of HTML lets you add your company's icon to  your web page
  23. Do you know where to add design files for deployment?

    When a designer (or a developer) adds design/style files to SharePoint - care must be taken regarding where the files are placed:

    • Some places are are not suitable because they are not good for deployment
    • Other places may have permission issues - designers can't access them
    • Some files are part of the site definition and should not be customized

    So our rules are:

    1. Never modify out of the box SharePoint files in /Style Library/ - those files are part of the site definition, if you customize them they are hard to deploy
    2. Start with a clean, minimal masterpage
    3. Create and reference your own CSS files and put them under /Style Library/CSS//
    4. You may want to further divide your CSS paths according to the areas of the site that your CSS is designed for:
      E.g. /Style Library/CSS/SSW/Clients/layout.css
    5. Designers can modify the XSL file as well!
      put them under /Style Library/XSL Style Sheets//
  24. Do you know why you need to use solution package instead of deployment manually?

    As a server product, SharePoint supports lots of configuration, but the support for packaging and deploying changes between servers remains very week.

    The experts agree that the best and preferred way to package a set of changes is to build a solution package.  A SharePoint solution package includes all the components and dependent files packed in a cab file.

    There are many reasons why you need to use solution package:

    1. All dependent files and components are in the package - allowing developers to quickly deploy development, testing, staging and production servers. 
    2. Manual steps are very long, and error prone
    3. Solution packages are easy to retract
    4. Minimize downtime in the SharePoint production server during an upgrade operation
    5. No content data loss during upgrades - SharePoint backup/restore deployment methods will block users from making changes to the production the site during the upgrade period
  25. Do you know you can't think of data the same way?

    In SQL Server you have tables to store data.  Then you have Views, Relations and Stored Procedures.

    SharePoint gives us Lists where we can store rows and columns of data, but it is not the same as a full database.

    • There are no joints out of SharePoint – you can do limited operations with lookup fields but they are not the same as joints in SQL Server
    • Views in SharePoint are filters, grouping and sort on a single list only.
    • Formula fields in SharePoint are only updated when the row is changed.  If you change the lookup value in the lookup list, it will not change any of the items using formula fields that are currently referencing that lookup.
    • No stored procedures in SharePoint

    Database remains the best at doing database work.  SharePoint is OK at creating quick lists and working with simple lists, but it is not a database server.

  26. Do You Let Your Designers Loose on SharePoint?

    Do you let your designers loose on your development SharePoint?

    This is how we work:

    • A designer would imagine and mockup the design using a graphics tool – such as Photoshop
    • After the mockups are signed off, we let the designers work on the actual page
    • Give them designer permissions to your development site and let them loose with SharePoint designer!

    There are many reasons why we believe that designers should work directly in SharePoint, with SharePoint designer:

    • In all areas of .NET development, whether it be ASP.NET, WCF or SilverLight, designers are more and more involved with the actual project beyond mockups
    • It helps them understand the limitations of SharePoint, which helps their future design to play to its strengths
    • They are also better at CSS and DOM than a typical developer, as well as more cross-browser aware
    • They are able to make a call on how close a designer can be bent when the implementation is hard or impossible - with developers who can't make that call, they may end up spending a lot of time failing to get the last 2 pixel perfect
    • SharePoint designer is sufficiently powerful and offers the only experience currently available for building with SharePoint sites
    • SharePoint has built-in check-in and check-out, as well as version controls, publishing and approval controls - all of which are excellent for team development

    The major drawback for a designer is the complexity of a SharePoint masterpage:

    Figure: Bad - Nasty looking masterpage

    Luckily, we always start with a clean-minimal masterpage, which gives our designers full freedom to implement their vision:

    Figure: Good - clean-minimal masterpage

  27. Do you use content editor web part with care?

    The Content Editor Web Part is very easy to use in any web part zone, and gives your content editors ability to add additional text and flair to a page.
    Figure: Content Editor Web Part – available in any web part zone

    However, there is a scary hidden trap!

    Figure: Content Editor Web Part looking mostly harmless...  
    So what’s bad with the Content Editor Web Part?
    • The content in a content editor web part is not version controlled.
    • If an editor accidentally overwrites a previous copy – there’s no way to go back.
    • If an editor accidentally deletes a Content Editor Web Part – the content in it is lost.
    • Data loss is always bad – and Content Editor Web Part gives you many different ways you can easily lose data... you need tread carefully and know the risks!

    The best practice is:
    1. Do your content editing in the Content Editor Web Part, or in SharePoint Designer.
    2. Click the Source Editor button afterwards to get the raw html view.
    3. Copy and save this to a plain HTML file, and save the file in the page library (which is version controlled).
    4. In the Content Editor Web Part – link to the HTML page’s URL.
      a.If the text is very tiny – may be just a big heading, you may not want to do this.
      b.Using Content Link is also another way you can re-use the same text in different web pages and update them in one place – very good for big banners.
    Figure: Using Content Link to a file - safely stored in the document library. This gives us the best of both worlds
  28. Fix HTML - Do you implement CSS friendly?

    It is extremely important to make your site standards compliant:

    • It makes styling a lot easier.
    • It also means your site is likely to work for all browsers, even if you don’t specifically target/support them.
    • It requires accessibility for big public sites can be met easier.

    When you first run your SharePoint site – you’ll discover that it looks nice on the surface but needs a significant amount of work to fix all the bad HTML.

    Implement CSS Friendly – these are the control adapters released by Microsoft to make ASP.NET render better, non-table based controls.  You can implement them for SharePoint sites as well.

    <TABLE id=zz1_TopNavigationMenu class="..." border=0 cellSpacing=0 cellPadding=0>

            <TABLE class="..." border=0 cellSpacing=0 cellPadding=0 width="100%">
            <TABLE class="..." border=0 cellSpacing=0 cellPadding=0 width="100%">
            <TABLE class="..." border=0 cellSpacing=0 cellPadding=0 width="100%">
                    Application Management

    Bad example - without using CSS Friendly

        <ul class="CssFriendly-Menu">
            <li class="CssFriendly-Menu-WithChildren">
            About Us


                    <ul class="first">
                        <li class="CssFriendly-Menu-Leaf">



Good example - using CSS Friendly