Want to know how to go about creating a ".NET Applet"? - a Windows Forms control hosted within a web page? A good tutorial is available at
http://www.developerfusion.co.uk/show/4683/
Friday, April 01, 2005
Not as nerdy as I used to be
Thank god age means something. I recently took the nerdy score and am now only somewhat nerdy. A big improvement from the past. I think memory loss and old folk habits helped reduce the score. Click the link below and find your own "nerdy score."
Table Rendering
From Microsoft Blog.
“IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. Internet Explorer 6 introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
“IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. Internet Explorer 6 introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
Mark of the Web
From Microsoft Blog
A comment from Dave P on this blog touched on the interesting aspect of table rendering.
Dave said “IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
A comment from Dave P on this blog touched on the interesting aspect of table rendering.
Dave said “IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
Subscribe to:
Posts (Atom)