Tags:
create new tag
, view all tags
This page is intended as a test page to compare HTML rendering (specifically of TWiki) in different browsers. See Support.BrowserFormattingIssues.

Update: This page is not currently up-to-date. When I (or someone else) update this page, I should consider a different approach. I made this page by copying BrowserFormattingIssues here, and then adding test cases for each issue (where possible). That makes updates a little more difficult than I'd like so I think the aproach I'd like to take is refactor this page to provide separate test pages for each issue linked from BrowserFormattingIssues. Then I can add test pages for new issues by just adding additional links on that page.

Note: If you edit this page, please take care to leave the critical test pieces as originally intended. Changes may occur if you aren't paying attention, and may occur inadvertently, due to some quirk of your browser or TWiki. I can't recall this happening on TWiki so far, but it has happened on the C2 Wiki on the lists of wiki sites (I should get a page reference). I can't explain what happened exactly without thinking about it or checking back again, but I had everything formatted as bullets. Some (unknown person) apparently saved the page with the wrong setting of the "I can't type tabs, please convert spaces to tabs" option, and the bullets are now shown as asterisks.

As RichardDonkin has pointed out, the HTML standard doesn't specify browser presentation. From the point of view of the HTML standard, browser builders have freedom to choose how they wish to present HTML documents. Nevertheless, it is useful to know about differences in presentation between browsers. Also, IMHO, it would be useful to have a presentation standard.

Additions and improvements are welcome.

Aside: This page developed primarily because I noticed some discrepancies between the way Konqueror and IE rendered TWiki pages back in the days of Konqueror 1.9.8. I noted those discrepancies on Support.BrowserFormattingIssues and developed some habits to minimize the differences. This test page will help me (or anyone else) check to see if those problems have been resolved with more recent versions of Konqueror and see if other browsers have similar problems.

Table of Contents

Generic Issues (All Browsers)

Two Spaces after a Sentence

Most browsers convert two spaces at the end of a sentence to a single space. See TwoSpacesAfterASentence.

Test

The sentences in this paragraph each have two spaces after the closing punctuation (., !, ?). Can you see any difference compared to the next paragraph? Surprise! Thank you for flying USAir.

The sentences in this paragraph each have one space after the closing punctuation (., !, ?). Can you see any difference compared to the previous paragraph? Surprise! Thank you for flying USAir.

Using <div> Tags to Control Wrap Width

This topic might belong on a different page, and could probably use some editing:

In a "big brother" like attempt to improve readability, I modified my TWiki view template to limit the line length on my home TWiki to 90% of the full window width (the full window width is usually the full screen width). I did this by enclosing the %TEXT% variable in a table with the width set to 90%.

This worked fairly well, but long preformatted lines (enclosed in <pre> or <verbatim> tags) forced the window to be as wide as the longest preformatted line. Then non-preformatted lines wrapped at the same width, forcing a reader to scroll horizontally to read any line.

A div tag, like <div style="width: 90%"> can achieve the same result as the "table width=90%", without the problem caused by long preformatted lines.

I've seen the same problem on other web pages and wikis due to wide tables or graphics -- I haven't tried to confirm that the div tag approach solves the problem for wide tables or graphics.

The <div style="width: 90%"> tag is not effective in Netscape Navigator 3.0x (for Windows).

Aside: I eventually realized that the original problem only occurs when text is "enclosed" in a table -- Web pages with text not enclosed in a table behave more sanely -- the browser window widens to accomodate the wide preformatted line, table, or graphic, but the other text wraps at the width of the window.

I also realized there were some differences in behavior between konqueror and IE5 -- what's been described so far is typical of IE5, konqueror wraps the long lines of preformatted text, which seems preferable, so far.

(On my home TWiki I added a new TWiki preference variable, %VIEWWRAPWIDTH% to allow a user to adjust the wrapping width. I haven't yet figured out how (haven't really tried) to automatically include this on each user's home page.)

UPDATE 20010726: I need to make the change in register.tmpl.

Test

I don't believe I can test that on this page without causing a lot of confusion -- the entire content of this page is probably rendered within a table (original TWiki templates), a div (templates on my home TWiki), or neither (??). Inserting another table or div here in this document will then result in nested tables, divs, tables within divs, or divs within tables, any one of which may be totally unworkable and will not be indicative of the situation without such nesting. I may devise a test page for this at some point in the future -- probably a completely separate HTML page, not to be rendered within TWiki.

Browser-specific Issues

Konqueror (1.9.8 and 2.1) (vs. IE5)

Vertical Whitespace

konqueror handles vertical whitespace differently than IE5:

  • konqueror does not delete extra vertical whitespace, while IE5 and most other browsers do (??). (I like the konqueror behavior -- I like being able to display extra whitespace at my discretion.) Test: There are three blank lines between this and the next bullet -- Konqueror 1.19.8 would show three blank lines, IE will show only one.

  • In konqueror I have found no way to insert a single blank line between elements of a bulleted list (tagged, e.g., <UL><UL><LI>item</UL></UL>). A single blank line (in the edit window) is rendered as two blank lines. No blank line is rendered as no blank line. Thus, vertical spacing that looks appropriate in IE5 (IMHO) looks excessive in konqueror.
  • Test: There are no blank lines between this and the previous bullet. Konqueror 1.9.8 and IE will show no blank lines.

  • Test: There is one blank line between this and the previous bullet. Konqueror 1.9.8 would show two blank lines and IE will show one.

    • Repeating the last two tests for deeper list elements:
    • Test: There are no blank lines between this and the previous bullet. Konqueror 1.9.8 and IE will show no blank lines.

    • Test: There is one blank line between this and the previous bullet. Konqueror 1.9.8 would show two blank lines and IE will show one.

Similarly, between a plain text paragraph (no HTML tag) and the first item of a bulleted list, I have found no way to avoid a blank line. A single blank line (in the edit window) is rendered as two blank lines. No blank line is rendered as a single blank line. Thus, vertical spacing that looks appropriate in IE5 (IMHO) looks excessive in konqueror.

    • Test: There are no blank lines between this and the previous bullet. Konqueror 1.9.8 and IE will show one blank line (I think -- need to confirm).

    • Test: There is one blank line between this and the previous bullet. Konqueror 1.9.8 would show two blank lines and IE will show one (I think -- need to confirm).

  • The same behavior described above (no way to avoid a blank line, a single blank line is rendered as two) occurs between:

    • A heading (e.g., <h3>) and a plain text paragraph

    • <more to come?>

Test Heading 1

    • Test: There are no blank lines between this and the previous Headiing. Konqueror 1.9.8 and IE will show one blank line (I think -- need to confirm).

Test Heading 2

    • Test: There is one blank line between this and the previous bullet. Konqueror 1.9.8 would show two blank lines and IE will show one (I think -- need to confirm).

Extra Blank Lines after the Signature after Editing

    • (This might be a combination of a konqueror and a TWiki issue.) When doing common editing tasks in konqueror, extra blank lines often get added after the signature line. In most browsers it's not an issue because extra vertical white space is not displayed. Konqueror does display this extra vertical white space. I try to make it a practice to delete extra blank lines before saving when I edit in konqueror (and in IE5 when I remember). (ToDo: Determine whether the extra inserted blank lines also occur in other browsers and just aren't seen, or if the addition of blank lines is konqueror specific. I may attempt to modify my installed TWiki (20010315 beta) to strip blank lines at the end of a topic automatically.)

Test: To test this, you must:

  • Edit this page, confirm there are no blank lines after the last line of content (usually the signature), then preview and save the page.
  • Edit this page again (click on edit, don't use the browser back button), and confirm there are still no blank lines after the last line of content. At this point you can cancel the edit to ensure that no blank lines are added for the next tester (who should confirm there are no blank lines before he does the test in any case).

Line Wrapping

See also Line Wrapping Anomalies for some testing / results / discussion.

  • See Using <div> Tags to Control Wrap Width, above.) Konqueror "wraps" long lines of text enclosed in <verbatim> tags, IE5 does not. Thus, in IE5, you must scroll horizontally to see the entire line. Further, IE5 increases the width of the "virtual" display window to the width of the widest element on the page and then wraps other ordinary text at that width (20010723: I now realize that this is a consequence of "enclosing" the text in a table). Therefore, you must scroll horizontally to read most text on the page. (I like the konqueror approach. Aside: neither IE5 nor konqueror will wrap URLs which are longer than a line.)

Test: Testing this is probably not a good idea for two reasons:

  • if the test causes your lines to not wrap at the width of the window, reading this page will be frustrating
  • part of the behavior here depends on whether the main content of the TWiki is enclosed within a div or table, which is not directly under control of what I put in this content area, it depends on the template that is set up for this TWiki.

Nevertheless, I have included a long line below which can be enclosed in verbatim tags or not by editing the page. (Just in case the verbatim tags disappear, and you are not familiar with verbatim tags, enclose the line below with <verbatim> </verbatim>.)

Here is a long line of text enclosed in verbatim tags. Does all of your text wrap at the length of this line, or does the non verbatim text wrap at the width of your window?

Here is the same long line of text not enclosed in verbatim tags. Does all of your text wrap at the length of this line, or does the non-verbatim text wrap at the width of your window?

Here is a long line of text enclosed in verbatim & pre tags.  Does all of your text wrap at the length of this line, or does the non-verbatim text wrap at the width of your window? Does it? Nope, I dont think so :)

Well, I'm not absolutely sure that those are long unwrapped lines because they don't wrap in any of the browsers I tried today -- IE 5, Konqueror 2.2.1, and Mozilla 0.9.8. However, I did take the lines to nedit and NotePad and confirmed they were not wrapped their and brought them back. I suppose this is an OK test until I find a(nother) browser that causes non-wrapping of the non-verbatim lines. (Remember that the behavior here also depends on the template -- whether in encloses TWiki content in a table or in a div.)

NEW 20010725: Initial Page Positioning

Konqueror 1.9.8 does some funky things with respect to the initial positioning of a page after loading. It seems to never be positioned to read the top of the page (unless the page is one screenful or less). For most normal pages konqueror seems to position itself to the middle of the page. For bookview, it seems to position itself just below the top of the page (maybe it's the middle of the first page in the bookview?).

Reporting as Bugs

At least some of the behaviors listed above should be considered bugs in konqueror. Once I believe I have discovered most of the differences, and determine whether they have been changed in kde 2.2, I will submit bug reports to kde. If anybody is using konqueror 2.2 and can comment on its behavior, this section should be modified accordingly.

I should document the problems as differences from the standard behavior -- is what IE5 does the standard? wink (Maybe I can find a concise description of the standard HTML behavior with respect to vertical whitespace using Google -- I won't find it in the HTML standard. wink )

Contributors:

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2004-02-05 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look