Topics in the world of web development and other technologies we find interesting.

Blue Valley Technologies - TechTalk

We want to give back! We have learned much of what we use everyday by others that have taken the time to post that information to the web. Here is where we will post the things that we hope will in turn be useful to others as we explore the technologies in web development and any other topics we find interesting.
You are free to use any of the code snips or techniques that we have posted here for any purpose, personal or commercial. However if we credit another individual or group please visit their website for information about their usage terms.

Do HTML Embedded CSS Styles have a place?

I have long subscribed to the argument that the design (CSS) should be separate from the content (HTML). The theory makes a lot of sense. It allows for the design of the site to be changed and tweaked without needing to go into every single page and adjust the code like was common years ago. Websites like illustrate this theory very well.

The one nagging problem however, is that most sites invariably end up needing some customized CSS styles applied to just one specific piece of content in order to meet the requirements of the client. You know, the pesky splash text that only appears on the home page for example. Or perhaps it is just one customer testimonial that was just a bit too long so you apply a tiny bit of negative letter spacing to make it fit. You end up with CSS style definitions like: #homepageBannerText or #smith.customer Testimonial. Are we really still separating content from style at this point? I would say no.

It gets really bad when you start creating sections for each page within the main stylesheet. I have seen sites that have ended up with over 20,000 lines in the main style.css as a result of this. I know everyone has different opinions on how to organize, but personally, a 20,000 line css file drives me nuts!

One of my recent projects entailed a website where the design was already done and we were responsible for taking the Photoshop comps and producing a website to match. The website featured a scrap-booking theme. This also meant lots of variation from one page to the next. It would require lots of z-index layering and special positioning of transparent images to get the desired overlaps and effects. What it boiled down to was nearly every page would need per-page CSS definitions, and lots of them.

I decided I would look for a new approach. Many would suggest a main style.css for all the site-wide css attributes and then one additional css file for each page that needed custom style definitions. While the organization of this appeals to me, I wasn't happy about the fact that this would also require another http connection increasing the load-time for each page. Especially on this particular site which was already very graphics intensive with lots of big images on each page.

I finally settled on the approach of a very similar method. Except that instead of putting the page specific css in a separate file, I just defined it in a style block at the top of that page. Much of the advice online says that this should be avoided, citing the separation of the content and style as the reason. My experience with this site showed that this technique actually worked out very well. Any style that applied to the entire website or at least to multiple pages was still placed in the main style.css as usual. It was neat, organized, fairly trim, and it was then cached by the browser for each consecutive page load. I still can alter any of the site-wide styles with ease if I ever need to. Every single page is no longer forced to download the CSS styles for every other page on the website, something that has always bugged me about the single CSS file method. After all, we don't have the browser download the content and images for every other page do we?

But because the per-page definitions were embedded at the top of the HTML, I also have not created an additional HTTP request. What I was surprised to learn was that this technique also made the CSS and HTML both much cleaner. I no longer needed to have site-unique ID's on everything that needed custom styling. I could simply override the global values on a specific element, say .stickyNote at the top of my page in my per-page css block. My custom values would apply to only that page just like I needed, without affecting any of the other global rules for other pages.

As far as separation of content and style goes, I feel I have not lost anything. The only rules that are in the HTML page are inherently tied to the content anyway. Even if they had been defined in the main style.css, they would need tweaking anytime the content changes. By putting them in the top of the page it actually makes this easier, while keeping my main stylesheet clean from all this clutter.

Posted by Mark at 11:45

Introduction to ASP.NET Master Pages

ASP.NET has a built in website template system called Master Pages. The system offers a very flexible and easy to use solution for managing the portion of a website that will be re-used on more than one page of the site.

Most websites will use the same header, navigation and footer on almost every page of the site. Master Pages provide a simple to use, and simple to manage answer for this common problem. Master pages are not the only option for this problem. Some developers have taken the time to build their own templating system (usually when using another development language that does not already have one built-in like ASP.NET), and some web design software suites include a template system. For example, Dreamweaver includes a system called "Dreamweaver templates". ASP.NET Master pages work similar to the Editable Regions in Dreamweaver templates, but they offer a number of advantages.

  1. The master pages are integrated into the content pages at the time of the user request. This means that unlike client side based templates, you do not need to re-apply it to every content page each time you change the master page.
  2. The ASP.NET Master Pages are much more flexible than most other template systems. Among many other features, they allow for an unlimited number of nested template levels and allow for default content at each content region. While nesting is beyond the scope of this article, it is actually quite simple to implement. I will discuss how to specify default content below.

The template files in ASP.NET end with .master and are very similar to a standard .aspx page in that they can contain the same kind of page markup. The .master file will contain the code that you want to reuse on multiple pages.

In the example below you will see the Site.master default markup for a new Visual Studio Web Site. By default there are two Content Place Holders defined with the <asp:ContentPlaceHolder /> tags. The first one is titled HeadContent and contains a single line of default content. The second Content Place Holder is titled MainContent and uses the shorter close tag notation since we did not specify any default content for this region. Because the templates are actually merged by the web server at the time of the request, we need to include the runat="server" parameter as well.

Site.master ASP.Net Masterpage

In the sample Content Page below we tell the server that we want to use our Master Page by adding the MasterPageFile="~/Site.Master" parameter in the Page tag at the top. The Master Pages content will now automatically be used on this page of the website and all we need to do is optionally provide some custom content for our Content Place Holders. We do this by using a <asp:Content /> tag. The page below has supplied content for both of our Content Place Holders. Notice how the tags are matched to their proper corresponding Master Page tag by the ContenPlaceHolderId parameter.

Default.aspx ASP.Net Page inheriting from Site.master

If we request the page from the web server, below is the resulting HTML that is sent to the browser. The custom content was automatically merged with the template content contained in the Master Page, and then the ASP.Net Placeholder tags were stripped out and finally the server would process any other server side elements before sending the results to the client. Notice also that setting the Title parameter in our content page was still applied even though the title tag is actually outside of any of our Content Place Holders. Any code behind files (.cs or .vb) that are associated with the pages will get processed just fine. Another nice feature is that you can even specify a code behind file for your mast page that so that it can be used to insert server code that you want to get processed on every page.

Resulting generated page: Example 1

Now if we decided we did not need to change the default content that we have for the header in our HeadContent Place holder, we would just omit specifying a corresponding asp:Content tag in our content page. If you omit a placeholder region in your page the server will then just use the default content from the master page instead, like below.

Resulting generated page: Example 2

This is especially nice if you decide to adfd a new Content Region to a template after the site has already been published. You do not have to go back and add that region to every page the uses your template. Instead you would only need to update the pages where you want to specify custom content in your new content placeholder.

This article really just scratches the surface with what can be done with master pages. However many sites do not need any more complexity then this. Nested master page will come in handy when you want to build a section of subpages, say recipes for example, that will all have a very similar look, but still inherit from the Main Master Page to inherit the site's header, footer, etc.

Posted by Mark at 14:25

My Budget? - Why Should I Tell You?!

Asking clients for their project budgets is a topic that I often see on design & developer forums. The consultants post that they would like a project budget when working on an estimate but are frustrated when clients are reluctant to provide it. The consultants usually post that they do not understand why this is. Before I became a consultant I was the IT Manager for several years at a non-profit organization. From that experience I can definitely understand a client's reluctance. In fact, I didn't understand why I should disclose my budget with a contractor until I became one myself.

Budget Size

From the client's perspective, there are usually two reasons that they may not want to divulge their budget. The most common reason is the desire to get the best price that they can. They fear that if they lay out how much they are willing to spend, then that is what the project will cost, and often they are right. Instead they are hoping that the contractor will just provide an estimate that is ideally less then what they were willing to spend. This is a basic concept and from the client's perspective it makes perfect sense.

The other reason a client may not want to discuss their budget is because they may not know what a suitable budget for their project really is. The fear is if they show what might be perceived as ignorance on the topic, then the contractor will take advantage of that, again resulting in them being overcharged. So far I haven't made much of a case for discussing a budget! However, that's because I think it is just as important for contractors to understand their clients' concerns as it is for the client to understand ours.

From the contractor's perspective, my goal is to provide a service or product to my client that both meets their needs and is priced at a point that is within their budget. The fact is that some projects can be performed at different levels of budget. However, this does not mean that the final result is the same. The difference is how much time and effort can be invested in producing and polishing that result. The budget is a key component in determining this. Another element that is often overlooked is that this is negotiable. I am more than happy to discuss options that may increase or decrease the cost. The budget just helps me to establish the initial project and what I can include at that cost point. My aim is then to produce the nicest product that I can within that budget. Without a budget I can only guess where to start, and that often results in an estimate that does not meet the needs of the client.

The budget always seems the most difficult to discuss when there is a new client / contractor relationship. Trust has not been established yet for the client, so this is only natural. Once trust has been established it is usually smooth sailing. The vast majority of my work is repeat customers or new clients that have been referred to me by my existing clients. If I were to take advantage of clients budgets, and provide results that were not a value to the client I could hardly expect them to hire me for more projects in the future, let alone expect referrals from that client. A smart contractor realizes that trust and integrity are key to future work and ultimately a successful firm.

Don't be afraid to provide your budget requirements to a firm when asking for an estimate. But at the same time, don't be afraid to ask for options that could reduce the cost. Make sure that you understand what those options are and whether they provide the value you expect at that price point. Then you can decide for yourself that the project features and polish are at a price that is a value to you and your organization.

Posted by Mark at 21:30


Recent Comments

Powered by Disqus Error loading MacroEngine script (file: uBlogsyListBlogRoll.cshtml)