Master Pages for Different Browsers

CSS and themes

We are back to the basics: structuring a web page with CSS and ASP.NET.

Nowadays some habits such as using nested HTML tables to position content in the right place, are easily avoidable. We have to structure a master page that will be easy to maintain, complies with standards and best practices, meets accessibility requirements, and supports search engine optimization (SEO). We have to push all formatting and layout directives from individual pages to style sheets, which leaves less markup in our individual web pages and allows the same style sheets to be reused. They can also be called container-specific master pages.

Journey to master pages from links

In the world of web development, we didn’t always have master pages. Their use evolved over time. In the beginning, we used hyperlinks, then tables, then style sheets, and now master pages. The journey was from hyperlinks to tables to style sheets to master pages.

In the 1990s, you could make links, lists, and headers only. Then tables were introduced. Here, you could line up elements and structure content in columns. Soon, there was more markup than actual content. This created a high “signal-to-noise ratio” for most web pages. When you have nested tables in your design, more markup code is being laid out for format and layout.

So, style sheets were introduced. They made content easier to find and edit. Style sheets make our web pages more standard compliant, more easily maintained, and bring the focus back to content. Lastly, master pages were used to improve consistency across a web application.

To make improvements with master pages people began refactoring code, which is a disciplined approach for changing existing code by modifying its internal structure without changing the external behavior. Refactoring includes techniques for bringing code in line with best practices. The concept of refactoring HTML is a relatively new discipline.

Viewing in different browsers

It is important to view your page in various web browsers, at various resolutions, and on various devices. If your page does not render well in a particular browser, then you might be relying on browser-specific markup. If a page renders well on a smartphone but not on a widescreen, or the page renders well on a widescreen but not on a smartphone, then a fluid design should be adopted.

Examples of the same web page on both Google Chrome and Firefox.

All main structural elements should have an explicit ID attribute specified. Content placeholders provide configuration points where individual pages can provide custom content. Headers and footers cannot be overridden.

The Content Area and Side Bar are standardized when it comes to styling or positioning. A Script Manager and Validation Summary Control are included.

These are the elements that every page will need most. Hence, these elements are defined in the master page. All formatting and positioning directives are isolated to style sheets.