Website designers have been utilizing CSS (Cascading Style Sheets) for many years now. Over and over again, however, I come across an argument that CSS offers no real advantage and whether you code with it or not is just a matter of preference and habit.
I couldn't disagree more.
If you are looking to improve the presentation of your website, CSS will help you do it more efficiently and effectively. CSS based design offers advantages that table-based layout can't compete with.
And here's how:
Faster loading of pages
First of all, you are separating the content of the web page which is text and images into the HTML file and the visual presentation such as the layout, style, color etc. into a CSS file. This minimizes the amount of code in the actual webpage so the loadtime is shorter.
Also, designing a layout using tables requires much more HTML coding then if you were laying things out using CSS. With CSS, the usual table tags such as "td align" or "td width" are replaced with "divs". Code for specifying margin, padding, width, height and other visual details is much more consolidated with CSS. What used to take 200 characters with HTML, may take 50 when coding with CSS. Simply because CSS have cut the use of too much markups, websites can load a lot faster than using tables which is good when attracting visitors to a website.
With these two working hand in hand, the difference is substantial.
Efficiency
Since the content is separated from the layout styles, redesigning is a snap with CSS. All you have to update is the CSS file and the changes will be carried across the entire structure. No more digging through the site, page by page, to update a single tag. Because the layout information is centralized, these changes can be made quickly and globally by default. Markup tags are also much easier to locate since they can be logically organized in your file.
Consistency
As you only update a single file (although you can have many CSS for a single website), the style that you specify applies to any page that you want consistently, without any chance for diversion. This is most evident with positioning. Widths, heights, and margins will be handled the same by any HTML page linking to the same CSS file. You will improve your site's usability, credibility and overall user experience.
SEO advantage
There is a debate whether the use of CSS has any direct impact on SEO. I would say that Google (and any other search engine for that matter) do not have any preference and will certainly not give you any advantage just because your site is CSS based. However, just because there is less code (less messy code) involved, spiders will have easier time crawling your site. And it's known for a fact that they love clean code (just as much as valid one).
Layouts and design sophistication
CSS offers freedom in designing that HTML tables never might. While tables are rigid, inflexible, and grid based, CSS-based designs are fluid, flexible and expandable. That gives designers more power and freedom to exercise their creativity. For example, CSS offers absolute positioning of elements paired with the z-index property. This allows CSS-based designs to position elements on top of one another (like layers in Photoshop), allowing for more unique, complex, and beautiful layouts.
Bandwidth efficiency
A stylesheet is usually stored in the browser cache, and can therefore be used on multiple pages without being reloaded, increasing download speeds and reducing data transfer over a network.
And the 7th reason why you should use CSS? All the cool people gave up tables ages ago :)
Monday, 15 February 2010
Monday, 1 February 2010
Disable View State for a Page
You can disable a control's view state if the control does not contain any dynamic data, its value is hard-coded, or its value is assigned on every page request and you're not handling its events.
Introduction
The ASP.NET view state is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. This hidden form field can easily get very large, on the order of tens of kilobytes. Not only do large view states cause slower downloads, they also lengthen postback request times because the contents of this hidden form field must be included in the HTTP post back request. Unlike most other features of ASP.NET, view state can impact web pages dramatically, not only be in page size but also in server side performance. Moreover, pages with large view states can throw unexpected errors.
A key thing to remember is that view state is enabled by default for every control on every page. Since many server controls defined on a page contribute to view state size, your page’s view state will grow very large and impact performance if left unchecked.
When to Disable View State
You can disable a control's view state if the control does not contain any dynamic data, its value is hard-coded, or its value is assigned on every page request and you're not handling its events.
A good example of a big consumer of view state is .NET’s DataGrid control. It is desirable to disable view state for a page if the page does not post back. However, if the DataGrid has sorting or paging enabled, then enabling view state is desirable.
When you complete a web page, review the controls in the page and consider what information is being passed in the view state and whether you really need all that information to be maintained. To optimize web page size, consider disabling view state in these cases:
* When a page does not postback to itself
* When there are no dynamically set control properties
* When the dynamic properties are set with each request of the page
How to Disable View State on a Page
To disable a page’s View State, add the code below in the Page class of the page. In this example, the page’s class name is ShowOrdersTablePage.
C#:
public ShowOrdersTablePage()
{
this.Init += new EventHandler(Page_Init);
}
private void Page_Init(object sender, System.EventArgs e)
{
this.EnableViewState = false;
}
Introduction
The ASP.NET view state is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. This hidden form field can easily get very large, on the order of tens of kilobytes. Not only do large view states cause slower downloads, they also lengthen postback request times because the contents of this hidden form field must be included in the HTTP post back request. Unlike most other features of ASP.NET, view state can impact web pages dramatically, not only be in page size but also in server side performance. Moreover, pages with large view states can throw unexpected errors.
A key thing to remember is that view state is enabled by default for every control on every page. Since many server controls defined on a page contribute to view state size, your page’s view state will grow very large and impact performance if left unchecked.
When to Disable View State
You can disable a control's view state if the control does not contain any dynamic data, its value is hard-coded, or its value is assigned on every page request and you're not handling its events.
A good example of a big consumer of view state is .NET’s DataGrid control. It is desirable to disable view state for a page if the page does not post back. However, if the DataGrid has sorting or paging enabled, then enabling view state is desirable.
When you complete a web page, review the controls in the page and consider what information is being passed in the view state and whether you really need all that information to be maintained. To optimize web page size, consider disabling view state in these cases:
* When a page does not postback to itself
* When there are no dynamically set control properties
* When the dynamic properties are set with each request of the page
How to Disable View State on a Page
To disable a page’s View State, add the code below in the Page class of the page. In this example, the page’s class name is ShowOrdersTablePage.
C#:
public ShowOrdersTablePage()
{
this.Init += new EventHandler(Page_Init);
}
private void Page_Init(object sender, System.EventArgs e)
{
this.EnableViewState = false;
}
Client Side State Management Techniques
There are two types of state management - server side and client side.
Client side state management include the following techniques:
* ViewState - ASP.NET track the state of the controls on the pages through
the ViewState. Also, ViewState is used to store small custom values.
Don't hold big custom data object because it will affect the performance of
your web page.
* Hidden fields - hidden fields are html input control with a type of hidden -
. They are used to store data in the html without presenting
the data in the browser. The data of hidden field is available when the form is
processed or when using javascript. The ViewState use hidden field to save its
data. You can use the View Source operation (if enabled) to scan the web page's
source and to look for hidden fields.
* Query strings - query string state is stored in the URL that is sent to the browser.
Unlike ViewState and hidden fields, the user can see the values without using
special operations like View Source. The parameters are passed in the URL
separated by the & symbol.
For example, in the following URL the query string is built out of two data
parameters, a and b, which hold the values 1 and 2 - http://www.srl.co.il?a=1;b=2.
* Cookies - the cookies store their values in the user's browser and the browser
send them back to the server every time a request is performed.
Cookies are maintained during the session of a user in the web site and therefore
can be used in multiple web pages of the site.
* Control state - when building custom controls you should use the control state
to save your state if EnableViewState property is set to false.
This is the only reason to use this technique.
How do you know when to choose the client side or server side state management?
When to Choose Client Side State Management
Choose client side for better scalability and support multiple servers. The client side helps to get better scalability by storing state data in the user's browser instead of using the web server's memory. The client side support multiple servers because all the state is located in the browser. This way when you are redirected to another server you don't need to worry about your state.
The thing I wrote doesn't means that you can't use server side state management for the supporting of multiple server. To enable server side state management to be able to support multiple servers you'll have to use centralized state management (state server or store state in database) or you'll have to use techniques like sticky
connection for load balancing.
When to Choose Server Side State Management
Choose server side for better security and to reduce bandwidth and web page's size. Server side state management is more secure. The state is saved on the server and therefore isn't delivered to the client.
Confidential state data shouldn't be used with client side state management. Server side reduce the traffic to and from the client because data isn't sent to the browser and it's saved on the server. You should always remember that using client side state management sends data to the user's browser and that data is sent back to the server
every time. This situation increases bandwidth usage and therefore your application will be less responsive and you'll suffer from performance issues.
Client side state management include the following techniques:
* ViewState - ASP.NET track the state of the controls on the pages through
the ViewState. Also, ViewState is used to store small custom values.
Don't hold big custom data object because it will affect the performance of
your web page.
* Hidden fields - hidden fields are html input control with a type of hidden -
. They are used to store data in the html without presenting
the data in the browser. The data of hidden field is available when the form is
processed or when using javascript. The ViewState use hidden field to save its
data. You can use the View Source operation (if enabled) to scan the web page's
source and to look for hidden fields.
* Query strings - query string state is stored in the URL that is sent to the browser.
Unlike ViewState and hidden fields, the user can see the values without using
special operations like View Source. The parameters are passed in the URL
separated by the & symbol.
For example, in the following URL the query string is built out of two data
parameters, a and b, which hold the values 1 and 2 - http://www.srl.co.il?a=1;b=2.
* Cookies - the cookies store their values in the user's browser and the browser
send them back to the server every time a request is performed.
Cookies are maintained during the session of a user in the web site and therefore
can be used in multiple web pages of the site.
* Control state - when building custom controls you should use the control state
to save your state if EnableViewState property is set to false.
This is the only reason to use this technique.
How do you know when to choose the client side or server side state management?
When to Choose Client Side State Management
Choose client side for better scalability and support multiple servers. The client side helps to get better scalability by storing state data in the user's browser instead of using the web server's memory. The client side support multiple servers because all the state is located in the browser. This way when you are redirected to another server you don't need to worry about your state.
The thing I wrote doesn't means that you can't use server side state management for the supporting of multiple server. To enable server side state management to be able to support multiple servers you'll have to use centralized state management (state server or store state in database) or you'll have to use techniques like sticky
connection for load balancing.
When to Choose Server Side State Management
Choose server side for better security and to reduce bandwidth and web page's size. Server side state management is more secure. The state is saved on the server and therefore isn't delivered to the client.
Confidential state data shouldn't be used with client side state management. Server side reduce the traffic to and from the client because data isn't sent to the browser and it's saved on the server. You should always remember that using client side state management sends data to the user's browser and that data is sent back to the server
every time. This situation increases bandwidth usage and therefore your application will be less responsive and you'll suffer from performance issues.
GridView or Repeater?
What is the difference between GridView and Repeater? This is one of the most common questions that beginners ask when they are trying to get familiar with data bound controls. Both of these controls have their own using context and I try to explain when one should use GridView and when it is okay to use Repeater.
As first thing I want to say that GridView is more complex and powerful control that offers much more functionality than Repeater. Repeater has better performance because it is not so complex and doesn't offer so rich functionality.
Repeater
Repeater is okay if you need to show data from some data source. It offers the basic rendering options: header, item, alternating item, separator and footer. It is really up to developer how to fill these templates. By example, it is easy to use Repeater to show read-only lists using templated elements.
Repeater is faster because it offers only basic data bound control rendering functionalities. If you want to show data and you don't need any complex features described below then repeater is the right choice.
GridView
GridView is rendered as table with columns and it is created to show data and let users to manipulate it. GridView offers powerful built-in features like:
* events for sorting data when user clicks on column heading,
* row selection,
* row operations like adding, editing and deleting,
* paging,
* command columns and events to handle the commands.
GridView is excellent choice if there is a need to show tabular data and also provide users with features described above.
As first thing I want to say that GridView is more complex and powerful control that offers much more functionality than Repeater. Repeater has better performance because it is not so complex and doesn't offer so rich functionality.
Repeater
Repeater is okay if you need to show data from some data source. It offers the basic rendering options: header, item, alternating item, separator and footer. It is really up to developer how to fill these templates. By example, it is easy to use Repeater to show read-only lists using templated elements.
Repeater is faster because it offers only basic data bound control rendering functionalities. If you want to show data and you don't need any complex features described below then repeater is the right choice.
GridView
GridView is rendered as table with columns and it is created to show data and let users to manipulate it. GridView offers powerful built-in features like:
* events for sorting data when user clicks on column heading,
* row selection,
* row operations like adding, editing and deleting,
* paging,
* command columns and events to handle the commands.
GridView is excellent choice if there is a need to show tabular data and also provide users with features described above.
Subscribe to:
Posts (Atom)