I highly suspected that the ContentPlaceHolder could be used in MasterPages for styles – we can use it for other things in the header, such as the page title – but had not actually tried it.
As my project grew and individual stylesheets continued to increase in number, the head section of my MasterPage was growing.
This was mostly an experiment of laziness…I had a good 20 pages created and it was working at the start, so I didn’t mind adding to the list of stylesheets in my Site.Master. It got to a point where, pressed for time, I didn’t want to add another ContentPlaceHolder to the Site.Master for fear that I’d not be able to compile and was now looking at over 30 views that needed to be addressed.
I seem to remember getting burned on MasterPages earlier in their life, where there were complications in trying to mix CSS into the header, and problems with the Title tag, etc. I am almost certain that, previously, if you had a ContentPlaceHolder in your MasterPage that you were required to have the corresponding Content tag in your sub page or you’d get an error.
Thankfully, this is not the case…at least not in ASP.NET 4.0.
Error-Free Extension
Thankfully, this is a really easy one to try out. I opened my Site.Master and added the following code to the <head> tag:
<asp:ContentPlaceHolder ID="CssExtensions" runat="server"></asp:ContentPlaceHolder>
I compiled and ran the site, and sure enough, no errors. I was able to hit the 30+ views in the application without any problem.
Next, I moved into the view I was currently developing and added a Content control. I created a new style sheet and added it to the CssExtensions Content area. I then created and applied a style to an image that had not previously been styled.
Running the application again, with no problem, I was pleased to see the style applied in the running site and the proper HTML written to the browser.
Benefits of the Break-Up
I’ll be moving the list of a dozen or so CSS files to their respective sub pages to help reduce the hit taken by the user the first time they visit our site.
Because our primary audience is rural market, specifically those without access to land-based high speed internet, we want to keep our pages small, especially on first load.
Of course, once the user has the file cached there is virtually no perceived performance benefit, but even reducing the number of requests to the server (which caching doesn’t always prevent) might be an advantage for someone still on dial-up.
No comments:
Post a Comment