Table Rendering


The information published in this post is now out-of-date and one or more links are invalid.

—IEBlog Editor, 21 August 2012

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.

Thanks
-Dave 

Comments (77)

  1. Anonymous says:

    > 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.

    It seems tables were originally intended to position content on a page:

    "The first proposal for HTML tables that I have a record of was documented by Dave Raggett late in 1993, based on discussions in earlier months. It proposed mark-up to layout potentially complex material in rows & columns on a display. The proposal was concerned with the layout to be achieved, and not to do with any logical or semantic relationships among the material."

    http://www.barry.pearson.name/articles/layout_tables/history.htm

  2. Anonymous says:

    This is the kind entry I had hoped for when this blog launched.

    Hoping for more info on what improvements exactly are in the pipeline. *Please* put in more support for CSS selectors! Adjacent siblings, attribute selectors, :hover, :active, etc.

  3. Anonymous says:

    Matthew, Yes that’s really what I meant. Positioning of complex data in a tabular format is different from the use of tables we often see where tables are being used to align and position content that is not tabular in nature. Frequently that use takes advantage of quirks in the original Netscape Navigator 2 implementation.

    Thanks

    -Dave

  4. Anonymous says:

    I personally prefer the Opera approach — just render the page so fast you can’t tell.

  5. Anonymous says:

    Dave, if you read the above link you can see that tables were infact also intended to be used for non-tabular layout, such as arranging paragraphs on a page.

  6. Anonymous says:

    "<blockquote>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.</blockquote>"

    Makes sense. So IE waits for data to come in only to tables, eh? Now, how many web pages use tables for layout? 99% of them out there? Maybe even closer to 100%? So, IE renders 100% of the web pages on the Internet only after all the data has come in, right? So, that makes IE’s approach better than other browsers… how?

  7. Anonymous says:

    Don’t you just hate it when markup is not accepted in comments? *Sigh* Omit the <blockquote> above.

  8. Anonymous says:

    Came back to say this quickly.

    So, if tables are not such a good idea for layout for IE browsers (since the whole page has to be downloaded first if it’s in a table), what is? Which other technologies are better supported? Not CSS, definitely – I can give you enough links about what people’s opinions of CSS support in IE is like.

    Let me summarize – you can’t use CSS on IE because the support still lies in the Jurrasic Age, and you can’t use tables for layout because IE will necessary choke up the display till the entire page loads because somehow that’s better.

    Are you saying that users should code only for your browser, and for no other?

    Or are you guys really just trying to cover up a bad cake with beautiful icing (which is also easy to see through)?

  9. Anonymous says:

    Matthew, Thats still not how tables have ended up being used.

    Rakesh, IE’s CSS support for absolute posiitoning is fairly solid. We know we have issues with float and do not currently support fixed posiitoning but many pages successfully use IE’s current level of CSS support. We know we’ve got work to do in thsi area but to say that you can’t use CSS at all in IE is incorrect.

    Thanks

    -Dave

  10. Anonymous says:

    Dave Massy,

    I have been reading this blog for some time now. The patience you have is nothing short of exponential.

    James

  11. Anonymous says:

    James,

    Thanks. Sometimes it gets a little frustrating šŸ™‚

    I try to keep an open mind but misunderstandings often persist.

    -Dave

  12. Anonymous says:

    Interesting article. I agree that dynamic table layout is somewhat clunky, but it certainly ‘feels’ faster, which on reflection I find slightly less aggravating than waiting overall. However, it’s entirely a matter of taste, and doesn’t arise as an issue too often…

    One big negative about dynamic rendering is that it introduces extra timing issues, as with the infamous low-bandwidth Slashdot margin bug (although this is now fixed). Yes, it’s Slashcode’s invalid markup that is the problem, I know.

    Unusually nested tables was one of the fuzz tests suggested by Larry Osterman after the mangleme tool was released. I tried to teach myself about the very very basics of automated browser testing. Here’s a summary of what I found:

    http://ieblogwatch.blogspot.com/2005/02/automated-testing-in-browsers.html

  13. Anonymous says:

    > Iā€™m assuming that Firefox does support this

    > attribute

    Yeah correct.

  14. Anonymous says:

    Dave, IE has a bit of a problem rendering table cells when there is a CRLF before the </td> tag. If a CRLF occurs before the </td> then IE adds extra spacing at the bottom of the cell. I work on Borland’s Delphi product which uses MSHTML for the ASP.NET designer and thus we have to format the resulting HTML and our users ran into this particular issue because our formatter added CRLF chars (and any necessary indentation chars) in the case. We’ve "fixed" our formatter so that it no longer adds the CRLF however this is an issue unique to IE. Below is a small table that illustrates the problem. To reproduce the problem simply save the table into an html page and add/remove a single CRLF right before the first </td>. Compare the two pages and notice the extra spacing on the page formatted with a CRLF. (hopefully the HTML will post correctly):

    <table cellspacing="0" cellpadding="0" width="840" align="center" border="0">

    <tr>

    <td width="840" colspan="2" height="20"><img height="20" src="data/spacer20.gif" width="840">

    </td><!– Add/remove CRLF before this TD tag –>

    </tr>

    <tr>

    <td align="left" width="280" height="50"><img

    height="50" alt="some image" src="data/foo.gif" width="280" border="0"></td>

    </tr>

    </table>

  15. Anonymous says:

    Dave, does this imply that IE(6) will support the application/xhtml+xml MIME-type in some (near) future? I don’t see that much other ways that don’t break existing behaviour.

  16. Anonymous says:

    That’s a nice attribute – I maintain a 1Mb page that is 1 table with > 7000 rows and use table-layout:fixed together with the colgroup tag to ensure that rows are displayed while the rest of the document is being rendered. Seems to work nicely in IE and Mozilla.

  17. Anonymous says:

    One potential problem with fixed layout to aid in table-based layout rendering is accessibility. As font size for a particular user changes, it would be ideal, or useful at least, for the table width to change proportionately. Not sure if IE’s table layout in CSS only works with fixed widths. A combination of em based widths, min/max widths (if supported!) would help create a layout that can stretch somewhat. All those sites that fix their width at just below 800px is really annoying when you need to, or want to, browse at a larger font size, and the whole table layout gets screwed up.

    Re CSS for layout instead: a lot of complex layouts can be achieved even with IE 6, although IE 6 would require you to have more HTML code and CSS to achieve what you could do in Opera/Firefox and other modern browsers with a lot less (adjacent selectors, immediate sibling selectors, and a few other CSS features which are all missing help in this area.)

    IE 5.x and 6 are unfortunately for me what Netscape 4 used to be a few years ago: the problem browser that is likely to screw up when you try to do the right thing. On the plus side, you can actually get a lot of complex layouts to work if you have time and patience and are not TOO purist about having to add extra markup or CSS to achieve this!

    Please add all the features people are asking quickly IE developers! I know you are in a tough situation, but you are costing lots of businesses more time and money in developing their sites (not to mention potentially more hosting costs for the extra bandwidth!)

    Ok, that was a bit unfair as one could always change their design, but it would be nice to change design for accessibility/usability/design reasons rather than technical limitations šŸ™‚

  18. Anonymous says:

    Steve Trefethen: Test this in Netscape 3 and 4 and you’ll find the same issue. I assume this is one of those behaviours implemented to maintain compatability with Netscape; I remember being bitten by it in 1997.

  19. Anonymous says:

    Thanks Dave,

    With this post and Vishu’s one there’s now some interesting contents on the IE blog.

    You say : "We know we’ve got work to do in thsi area but to say that you can’t use CSS at all in IE is incorrect."

    I agree but let me explain how I work with IE and CSS. First my html code is produced dynamically by a custom CMS (with a backend in PHP to render XML documents in real time). I don’t use any table at all just semantic HTML and CSS. The main layout can be switched to classical two or three elastic columns it uses floats and negative margins which works fine with all post version 4 browsers, of course some hacks are needed (mostly for IE).

    Then came the widgets (menu, search bar and so on) I use relative or absolute positionning with floating to make an horizontal menu for example and a lot of hacks for IE but it works. The main content use floats everywhere and need hacks (for IE).

    What is interesting is that it is possible to render correctly a complex document with a non static layout without tables nor templates even in IE (5, 5.5 and 6) and of course in more modern browsers.

    This kind of design let me change the design by swapping just one CSS file but it’s not so easy to create this CSS because of IE approach of CSS.

    You wrote that there’re some issues with floats, I agree too šŸ˜‰ but floats can be mastered with IE (5, 5.5, 6) by using the appropriate CSS hacks.

    First the holly hack :

    /* */

    selector

    {

    height: 1px;

    }

    /* */

    When content disappear in IE this hack seems to fix the floated element (I call it the IE float fixator).

    Then a more strange one :

    selector

    {

    zoom: 1;

    }

    this proprietary IE CSS attribute says "zoom at 100% for this element (!)" can sometimes correct some weird behaviours like background-colors not applied or text-align: right doing nothing for instance.

    It would be very interesting (at least for me) to document in depth the effect of these hacks (I know there’s already an entry in MSDN for hasLayout but more documentation would be a great thing).

    So it’s possible to use CSS only design with IE but it’s really a pain and something almost impossible for a beginer to do. Sometimes I’m forced to drop a cool design because it will not fit in this model even if there’s no issue at all with Firefox, Konqueror and Opera 7. IE costs me 90% of my time when doing a design.

    Of course I could take the easy way "tables, tables, tables…" as almost everybody does but I take care of accessibility so…

    In conclusion working in pure CSS (no table) with IE:

    – is really a pain,

    – costs a lot of time,

    – limits the possible designs,

    But it’s the only mean to push things like web standards and accessibility.

    Thanks for reading

  20. Anonymous says:

    Gecko table-layout CSS/DOM is defined here:

    http://www.mozilla.org/docs/dom/domref/dom_style_ref18.html

    More information about Gecko table layout can be found here:

    http://www.mozilla.org/newlayout/doc/table-layout.html

    Information about how the table-layout CSS attribute works in Gecko can be found here:

    http://www.w3.org/TR/CSS21/tables.html#width-layout

  21. Anonymous says:

    It’s easy to be critical of IE, but that’s not constructive, so I’ll spare you the usual ranting.

    It’s good to see that the IE team is acting to improve IE’s CSS capabilities, and that is to be commended. I hope that you will implement the full CSS 2.1 spec to the letter rather than just picking and choosing a few selectors that seem cool… if you were to perform such a thorough implementation of the spec then you’d really be leading the pack for the right reasons, and that would be something to be proud of. Is that the plan?

    And can I assume that full PNG support will finally be implemented, and JPEG-2000 added?

  22. Anonymous says:

    Re #370947. ‘min-width’, ‘max-width’, ‘min-height’ and ‘max-height’ do not apply to table elements.

    Dave, is it possible that the IE team responds to the idea mentioned by Robbert Broersma above? The idea is about 8 months old ( http://annevankesteren.nl/archives/2004/06/standard-compliant-ie ) and the IE team still has not said *anything* about it.

  23. Anonymous says:

    Anne,

    I’ve seen this idea before. However I’m struggling to see how this is really very different to the DOCTYPE switching we support today. This is a technique we’ve used before to free ourselves from compatibility constratints and as I’ve said several times here we expect to use that technique again in the future.

    Thanks

    -Dave

  24. Anonymous says:

    Excellent article Dave šŸ™‚

    Just want to add the argument that table design feels much more "natural" to unexperienced web developers and is (if it isn’t really a nested table hell) easier to read (compared to classes or inline styles).

    There are dozens of articles out there which try to explain how to port the typical "header, 3 column, footer" page layout from tables to css. This can be a complex task – espcially when it comes to features like endless looping background images for a column or the question what "100% height" really means (viewport?/space an element can take without forcing scrollbar?/what to do in case of overlow?/what to do when multiple elements sum up to 120% height?/etc).

    CSS has no way to say something like "if -this- (e.g. overflow) happens to element A, apply -that- to element B". Table layouts do this somewhat, since they autmaticly stay a grid – no matter how small/big the content gets.

    Every browser has it’s little glitches here and there. Sometimes even the CSS2 spec is a little vague on detail question or leaves at least room for interpreting a situation in different ways.

    Tables have become stable and predictable over the years. You can create a simple website without the need to check it works exactly the same in every browser.

  25. Anonymous says:

    1. Have you traced the "support-other-one" way? šŸ˜‰

    /*

    * If we’re a fixed width cell and fixed layout (COLS) i..

    * BRAIN DAMAGE: It’s arguable that we should always do …

    * the cell was specified, we should respect it. However some

    * sites don’t look too good if we do…

    */

    this is from released sources of NN

    2. The question – why all items put inside of < /td>… < /tr>… space (wronly) are rendered outside of table? šŸ™‚

    3. Is there intensional support for rowspan/colspan crossing over ? šŸ˜‰

    Just see http://deep.kiev.ua for images crossin g each other without any css/bgimg. Strange but it works well for all browsers!

  26. Anonymous says:

    4. Is IE supports <table COLS=> (fixed rendering model of NN4)?

    5. You know when this style of page rendering is of most trouble? It is when someone use page counter (some external image) without image width/height specified and that site is down or too slow šŸ™‚

  27. Anonymous says:

    "Tables have become stable and predictable over the years. You can create a simple website without the need to check it works exactly the same in every browser."

    Not ALWAYS true. Much less, I know CSS can be complicated for layouts for new developers… but so was flash when we started out? It will always be this way, it is our industry; it’s just foreign at first. Once you get the swing of it, you are light years ahead — much less, you drastically cut down update and rebuild times — what’s there not to love?

  28. Anonymous says:

    The problem with DOCTYPE switching is that many developers already hack around (using such a strict DOCTYPE) for Internet Explorer. If Internet Explorer 7 or whatever it is called does not fix all those hacks (ignoring them) and does not support all appropriate properties and selectors a lot of websites will fail to display.

    Using MIME type switching there is no such problem. However, DOCTYPE switching seems like a good idea. I would propose though to use only the standard compliant in XML mode. And leave the switching thing to text/html rendering.

  29. Anonymous says:

    Michael Krax, there is indeed no such way that works cross browsers. However, have you heard of display:table? You can effectively imitate tables using CSS making all your problems go away.

  30. Anonymous says:

    > 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 is a CSS property. CSS doesn’t have attributes, HTML has attributes and CSS has properties.

    > It seems tables were originally intended to position content on a page

    I read a lot of Barry’s documents when they were first published. They left a lot to be desired when it comes to logic – he was arguing that examples of how to render an element type "prove" that HTML is visual-only, if I remember correctly.

    > This is the kind entry I had hoped for when this blog launched.

    I agree.

    > you can’t use CSS on IE because the support still lies in the Jurrasic Age

    That isn’t true. You can use CSS, only you have to restrict yourself to the subset of CSS that works properly in Internet Explorer, and deal with bizarre bugs. I find that I still come out ahead by using CSS for layout even after I take Internet Explorer into account.

    > One big negative about dynamic rendering is that it introduces extra timing issues, as with the infamous low-bandwidth Slashdot margin bug (although this is now fixed). Yes, it’s Slashcode’s invalid markup that is the problem, I know.

    No it isn’t. It’s a bug in Gecko, it was fixed a long time ago, but it didn’t make it into the 1.0 branch due to compatibility issues.

    > Dave, IE has a bit of a problem rendering table cells when there is a CRLF before the </td> tag.

    As I recall, Internet Explorer has a long-standing bug where whitespace that should be ignored by its HTML parser is not ignored. This is most commonly tripped when people attempt to style list elements as navigation bars. Perhaps this is a symptom of the same problem?

    [Re: application/xhtml+xml]

    > I’ve seen this idea before. However I’m struggling to see how this is really very different to the DOCTYPE switching we support today. This is a technique we’ve used before to free ourselves from compatibility constratints and as I’ve said several times here we expect to use that technique again in the future.

    I’ve tried to think of a way of expressing this more politely, but I struggled.

    I have zero confidence that a new version of Internet Explorer will be released that fixes all the problems with HTML, CSS, PNG, HTTP, etc *and* more-or-less correctly implements XHTML from scratch. I’ll be one of the first to celebrate if I’m wrong, but that’s my honest opinion.

    I suspect if this is attempted, we will end up having to support a whole host of major new bugs relating to XHTML that won’t be fixed for years.

    What would make me much happier is to see Microsoft release a new version that makes no changes other than fixes bugs and omissions in existing support for W3C specifications. I think this is a much more realistic goal and I don’t think it’s asking too much for Microsoft to catch up with everybody else.

    Now, in respect to doctype switching, I don’t understand your reasoning on this. I understand your reasoning when you originally introduced doctype switching, but now you need to support the developers who rely on bugs in your "strict" rendering mode as well.

    If you decide to honour bug-for-bug compatibility with the "quirks" rendering mode, and make all sorts of changes to "strict" rendering mode, then you are just punishing everybody who attempts to adhere to the specifications but didn’t get it quite right and rewarding the people who write for Interent Explorer 5.x to the detriment of other browsers.

    There are ways of introducing a new rendering mode without impacting on existing code. Why do you want to overload doctype switching in this way?

    > There are dozens of articles out there which try to explain how to port the typical "header, 3 column, footer" page layout from tables to css.

    This is because Internet Explorer doesn’t support CSS 2 properly (display: table-cell doesn’t work at all). If it did, none of those "dozens of articles" would be necessary.

  31. Anonymous says:

    Anyone here getting a blue line on more or less random position in the middle of the text when going to http://blogs.msdn.com/ie ? It’s rendering bug I think cause after scrolling the page down and then back up, the line has disappeared.

  32. Anonymous says:

    If any W3C contributors are reading this, can they please start designing a new ‘doctype’ – I suggest you call it ‘thisistherealdoctypenoreallyitispleasepleasepleaselistentomepleeeeeeease’.

    That way when Longhorn IE behavior deviates from the "strict doctype" specification Microsoft can have a fresh new goal of standards compliance to botch up.

  33. Anonymous says:

    I just want PNG and CSS support in IE, pretty please?

  34. Anonymous says:

    I know this because I’m filing the corners off a new website for my sister in law, a professional photographer here in Western Australia (http://www.goldenlight.bur.st/) and did the MSIE testing using RDP to a Windows 2003 Server box – my own household is 100% Open Source.

    Each page had at least three repaints at being rendered as MSIE re-jiggered the tables on the fly. It basically needs to use tables for NS 4.x support (don’t ask).

    FireFox on the same Win2003 box also reflows the tables on the fly, but it takes only two repaints to get it right.

    MSIE is the only browser I’ve found in which target="_parent" and target="_top" fail from within an <OBJECT> container. Every other browser responds to these by "breaking out" of the object. MSIE does not, so I had to use the more limited, deprecated <IFRAME>.

    Expanding on Daniel’s plea, and since you’re volunteering to fix MSIE, please make PNG images work right for the first time in history (full alpha, not just transparency, and do stop MSIE buggering up the backgrounds), and while you’re there please do the same for MNGs and ship the sucker with JPEG2000 support.

    I’m weary of paying a 40% size penalty and/or 66% colour resolution penalty every time I have to use a GIF instead of a PNG because *one* browser in the whole world doesn’t support PNG correctly. I’d also like to use the features in MNG which are not available in animated GIFs, and lack of widespread support is hampering the excellent JPEG2000 standard.

    To François Battail: I feel your pain. One recent pet hate is the way MSIE packs table cells, particularly vertically and especially when overlapping ROWSPAN= attributes leave a cell’s height in limbo. Konqueror does The Right Thing and packs it all topwards nicely. Gecko sometimes needs a hint or few, but only a few; forex if the unspecified row has any content at all Firefox at least sizes it to the content automagically. MSIE needs its hand held every single agonising step of the way.

  35. Anonymous says:

    Finding information about what Firefox supports for you is like finding information about what IE supports for me.

    You have to look for docs, they don’t come to you knocking on the door.

    Geez, I expected to find more intelligent content here than "my thing is better than yours".

  36. Anonymous says:

    I’d rather not go offtopic here, but I have a serious issue with IE and it just doesn’t fit anywhere else.

    Perhaps someone can help me. Why is it that IE’s support for the .png graphic format is severly limited? IE is unable to do proper transparancy with .png and it’s extremely frustrating. .png is an open format with more features than any other graphic format and has been the industry standard for years, yet IE doesn’t incorporate it into their ‘standards compliant’ browser.

    Unbelievable.

  37. Anonymous says:

    then IE will

    1) start supporting CSS propely,

    2) drop insecure activex crap (the biggest problem in the world, perhaps),

    3) support transparent .png’s,

    4) get tabbed browsing,

    5) adblock?

  38. Anonymous says:

    I am somewhat intrigued, and have some questions.

    1) You also mentioned that usability tests showed preferences for both table rendering methods. What proportion prefered incremental but faster, and what proportion prefered total but slower?

    2) A couple of posts ago, Bruce Morgan mentioned that Pocket IE is a completely seperate product to IE. Presumably it too renders the table completely before display?

    3) How about nestable XAML widgets? Will they be (are they?) rendered incrementally or totally? Or do you have the equivalent to the table-layour ‘css’ property already in place to prevent this problem? (Any Mozilla people who happen to be passing, same question about XUL widgets please!)

    4) Finally, you mentioned that IE DOES render some things incrementally. Could you please provide the most common examples which ‘matter’ – ie which might be visible on slower systems/more complex pages, and explain why?

    Please do more layout and rendering blogging!

  39. Anonymous says:

    Ron,

    You bring up an issue that has been discussed before and is well known. See http://blogs.msdn.com/dmassy/archive/2004/08/05/209428.aspx for a discussion and possible workarounds.

    Hi Riddler,

    Good questions.

    1) I’m not sure I mentioned usability tests. I’ve observed that some people prefer one way versus the other. It’s certainly not a scientific poll that’s taken place.

    2) Pocket IE is a separate product but it does use some of IE’s code as a basis. I’d expect them to be similar in this regard but can’t really speak for that team.

    3) There’s really no such thing as XAML widgets. XAML is a markup language for tying together .net classes. It’s particularly useful when it comes to Avalon the next generation presentation subsystem for Windows. Avalon has its own layout system that is entirely separate from IE.

    4) IE will render any page incrementally. When it encounters a table tag it will wait until it can measure the contents of the table before rendering unless the sizes are clearly specified. As someone pointed out many pages use tables but it is the situation of nested tables within tables within tables where this behavior becomes obvious.

    Thanks

    -Dave

  40. Anonymous says:

    As much as I would like to see Internet Explorer support more of CSS 2, I think it would be harmful to add it progressively. Unlike CSS3, CSS2 should really be an all-or-nothing implementation (with some notable exceptions given in the specification). Adding parts of it over the course of many versions/updates will just make it even harder to use CSS consistantly amongst everyone’s browsers.

    CSS 3 has carefully-defined profiles which allow the specification to only be partially supported without any major conflicts between browsers that support different profiles. In the short term, only implementing a vendor-defined portion of CSS 2 is more harmful than beneficial to web authors.

  41. Anonymous says:

    Why doesn’t the IE team drop the MSHTML engine completely ? It’s outdated and broken. There is a Free (as in speech) rendering engine Out There (Gecko).

    The end user won’t really care what rendering engine IE uses, they just want pretty websites, and the Gecko engine enables prettier websites (PNG Alpha, better CSS, etc.).

    IE’s market domination will force webdevelopers to write compliant sites, websites will look the same cross-platform and everyone will be happy.

  42. Anonymous says:

    All this talk about Pocket IE has got me thinking. Can I test to see if websites look OK in Pocket IE without a pocket device?

    The last thing I need is to check yet MORE browsers – at the moment I assume if it works in Firefox, IE and Opera then it’s OK, but I’d still like mobile users to have access if it’s not too much extra work. I certainly don’t want to have maintain different stylesheets unless absolutely necessary.

    Also, while the rendering will obviously be different between IE and Pocket IE, what is Microsoft doing to ensure idiosyncracies still be kept consistent as time goes forward?

    For example, if IE ever adds more support for CSS float positioning, can I assume that Pocket IE will add it too?

  43. Anonymous says:

    "In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content."

    do not work in IE

    <!– –><?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;“>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;

    do not work in IE:

    <?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;“>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;

  44. Anonymous says:

    Neither of those should ever be served to Internet Explorer anyway.

    Internet Explorer doesn’t support application/xhtml+xml. You can serve XHTML 1.0 as text/html instead, but only if you follow Appendix C of the XHTML 1.0 specification. Appendix C of the specification says you shouldn’t use the XML prolog (<?xml…).

    If Internet Explorer sees the XML prolog, it means you are serving XHTML as text/html without following Appendix C. This is against RFC 2854.

  45. Anonymous says:

    Agreed with Jim. There are plenty of ways (both by using server side scripting or web server rules) to serve application/xhtml+xml to proper browsers and text/html to IE. If you’re going to server side router (php/asp/jsp etc) then it’s easy to test to see whether the xml prologue is needed.

  46. Anonymous says:

    XML declaration. Just use HTML 4.01 when supporting IE.

  47. Anonymous says:

    What you fail to mention is that by setting the layout property to "fixed" you introduce a bunch of quirks to the sizing of complex tables. Cells do not size in the same manner, or even a predictable one somtimes (depending on the css styling added) with this layout property.

    What about fixing this in the upcoming ie7?

  48. Anonymous says:

    This blog helped me out so much with an issue I’ve been haveing with IE. I was getting those gaps between my tables due to adding a CR before my </td> tags. I thought I was going to go insane trying to figure out how to get rid of the gaps. I hope this gets fixed in IE7 because it’s quite annoying.

  49. Anonymous says:

    Main thing standards! 4 as webmaster always must check site both in IE and in Opera and Firefox. If all are make standard to me will be more simply.

  50. Anonymous says:

    *sight* Whining, whining…

    Read beneath "Incremental display" in the HTML-specification http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.5.1.1

    and you will get exact recommendations of how to implement table redering… "For large tables or slow network connections, incremental table display is important to user satisfaction. User agents should be able to begin displaying a table before all of the data has been received." etc.

    If the HTML is well written and follows the standards you do not get that "little off putting" feeling in Firefox you are talking about. But what the heck, why should the average HTML-writers follow the standards when IE doesn’t. šŸ˜‰

  51. Anonymous says:

    Problems the new IE could cause &lt;Anne’s Weblog about Markup &amp; Style&gt;

  52. Anonymous says:

    "there is a lack of documentation on exactly what is supported in that particular browser."

    Hey, look in the sources, they are open ….

  53. Anonymous says:

    In Polish order…

    Coin: that won’t wash with the typical user.

    Leachster: I agree, but they probably haven’t done it in the loose DTD because it will break existing IE-subservient pages that deliberately do that.

    picking at pocket: perhaps you can run a real Pocket IE in an emulator?

    Ron McKown: I think what they did was implemented PNG through the existing GIF support – which has only one bit of transparency – and buggered even that up by forgetting to mask out some kinds of transparent pixels. What I’d really like to see it support correctly OOTB is JPEG2000, then more people would start using that. Unfortunately, I think MS has their own wavelet-based image format being developed in the wings, which nobody else will be able to offer support for. That would be historically consistent.

  54. Anonymous says:

    Please tell me when rendering tables IE7 will support "empty-cells: show"

    I do a lot of work with tables of data.

    The fact that in every peice of code i write i have to do a test and if there is no value I have to add a no breaking space.

    I can’t make them look correct without putting a space in every cell.

    i can’t make a print friendly version without without putting a space in every cell.

    i can’t have a border without putting a space in every cell.

    I can’t make my code lean and efficient if I continue to put a space in every cell.

    So please do the right thing and support "empty-cells: show"

  55. Anonymous says:

    I can’t get IE to "speed up" incremental display of tables. Here is some quick sample PHP code to illustrate the problem with IE6

    ————————-

    Hello World

    <table border="1" sytle="table-layout: fixed;" width="650">

    <colgroup span="7" width="650">

    <col width="50"><col width="100"><col width="100"><col width="100"><col width="100"><col width="100"><col width="100">

    </colgroup>

    <tr>

    <td width="50">&nbsp;</td><td width="100">&nbsp;</td><td width="100">&nbsp;</td><td width="100">&nbsp;</td><td width="100">&nbsp;</td><td width="100">&nbsp;</td><td width="100">&nbsp;</td>

    </tr>

    <?

    for ($i=0; $i<1000; $i++) {

    echo "<tr>n";

    echo "<td>$i</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "<td>Testing if we can write out big tables</td>n";

    echo "</tr>";

    }

    ?>

    <script language="JavaScript">

    alert("Done with Rows");

    </script>

    </table>

    Done World

  56. Anonymous says:

    Apparently inline declerations don’t work. Using an embeded style seems to work (go figure)

    <STYLE TYPE="text/css">

    TABLE {

    table-layout: fixed;

    }

    </STYLE>

    Hope this helps others looking for incremental display fixs. Also, any JavaScript displays don’t fire until the entire page is loaded.

  57. Anonymous says:

    You said :

    "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."

    I am sorry to disagree. There is nothing more clunky than a slow site. If it is really by choice that IE is not rendering table progressively, I think you should indeed consider to change this behavior for your new version, or at least give the choice of how often to reflow a page to the user.

    http://jroller.com/page/design4speed/20050213#html_rendering_optimization

    I used to prefer IE among other browser some years ago for it was displaying quicker the images inside tables. But it was mainly because of modem access. This is no longer the same with broadband.

    I think that if you want to keep IE with its market share, the best insurance you can get is to build IE 7 the fastest browser to render the pages. This goes through :

    – table rendering

    – W3C norms full compliance

    – CSS non buggy implementation

    – HTTP/1.1 full usage, especially enabling pipelining

  58. Anonymous says:

    I really appreciate this blog post and especially Jim’s comment above.

    Tables for page layout are being deprecated, and are being replaced with styles (see blog post Feb. 27 05 at above handle for links. If IE cannot properly display styles, then Microsoft will own some responsibility for holding back the improvement of web design.

    Like Francois, about 75% of the time I spent redoing my site was trying to get the page to render correctly in IE. All the other browsers rendered the page perfectly according to ww3 standard css code. I ended up using a slightly inferior design to the one I would have liked in order to get it to work as well as it does now. I will try Francois’ hacks to see if I can get the css divs to align properly in IE (actually, they align in IE5/Mac but do not in IE6/Windows. Click on my handle to see.

  59. Anonymous says:

    I basicly don’t give a flying f when it comes to how IE renders tables, since I only use it for what it is intended to, listing out tabular data such as phone directories and sport results. In such use, Explorer does a good job. I guess this entire discussion exist of the single reason that people still uses nested tables to make their sites look allright in IE, because it is to much of a hassle to make it right with CSS because of the surprisingly bad rendering in IE.

    If you guys actually did what you say you did; "In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content", and let i.e padding and border be rendered outside instead of inside specified element width, much more website developers would have started to use semantic html and CSS instead of tables to create layout. And why on earth have you managed to confuse min-height and heigth? Height is heigth, and not min-height. I could go on and on, but I guess these three issues are the biggest reason that people use extensive and horrid nestet tables instead of the recommended way with css and semantic html.

    It would have been interesting to know how many billion dollars are being spent every year just from the single fact that borders and padding are rendered wrong in IE. Tens of thousands webdesigners spend hours every week to solve the mysteries of IE’s stupid misbehaviours. I mean, how hard can it be to make just this little issue right? I would guess a fairly skilled programmer would be able to change the crucial "inside" to "outside" in Exploders rendering engine in less than half an hour. It will maybe cost Microsoft a few hundred bucks, but it would save the millions of webdesigner’s customers billions every year, not to mention how many terrabytes in traffic that would have been saved from the change from massive use of table abuse to semantic html and nicely cached CSS. Do the world a favour, and read the CSS-documentation from W3C. They say very loud and clear how different CSS properties is supposed to work. I guess it is just as easy to do it right as to do it wrong, so please, do it right this time. Please please please.

  60. Anonymous says:

    Some <table> issues I’ve run in to:

    1. Table Footers

    In IE, using the THEAD, TBODY and TFOOT constructs, particularly when the TFOOT section appears after the TBODY section, the TFOOT sometimes appears as a blank row part way down the table. I realize the specification says that the TFOOT must appear before the TBODY, but that makes it much harder to include column summaries in the footer.

    2. Expanding Columns

    In IE, a fixed-layout table with no defined width which includes one or more columns with no defined width will stretch to 100% width. In every other browser I’ve tested, the columns with no width are not rendered. Looking at the W3C specification, this could be interpreted as the correct behaviour. Frankly, I think IE’s behaviour is much more logical, but it can catch you out if you do your primary testing in IE.

    <table style="table-layout: fixed;">

    <col width="100">

    <col>

    <tr>

    <td>Row 1</td>

    <td>This text will only be visible in IE</td>

    </tr>

    </table>

    3. Full-width Inputs

    In standards compliant mode, if you put a 100% width textbox in a table cell, the right-hand edge is cut off. In quirks mode, and in every other browser, the control is rendered correctly.

    <table style="table-layout: fixed;">

    <col width="100">

    <col>

    <tr>

    <td><label for="textBox1">Name:</label></td>

    <td><input type="text" name="textBox1" id="textBox1" size="20" style="width: 100%;"></td>

    </tr>

    </table>

    4. <col> Attributes

    In IE, many of the attributes applied to the <col> tag are applied to all of the cells within that column. Most other browsers seem to ignore everything except "width". Once again, this seems to comply with the W3C standards, although IE’s behaviour makes much more sense.

    <table>

    <col align="right">

    <col style="color: red;">

    <tr>

    <td>Right</td>

    <td>Left</td>

    </tr>

    </table>

  61. Anonymous says:

    "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."

    What universe do you live in?

    Umm, in all fairness Firefox not only has this (as well as just about everything else) well-documented, they also have the added bonus of correctly following established web standards so they don’t need to document a million ‘features’ that break the DOM or CSS box model etc…

  62. Anonymous says:

    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. ā€œ Actuall

  63. Anonymous says:

    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. ā€œ Actuall

  64. Anonymous says:

    Site build it work at home moms wahm. Work from home moms. Wahm com the online magazine for work at home moms. Amazon com work at home moms. Moms work at home. Work at home moms resource wahmpros.