I am now creating a test page with markup and instructions so that you can load the page and compare the behavior of your browser to that of other browsers -- Wikilearn.BrowserFormattingTestPage.

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, 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 this page and developed some habits to minimize the differences. I should consider checking to see if those problems have been resolved with more recent versions of Konqueror and see if other browsers have similar problems. I will consider making a test TWiki page (something like the test pages I made once during my TWikiEngineReview on C2 for comparing wiki markup languages).

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.

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.

List Items Can't Tolerate Blank Lines Between Them

I (and/or others) have discussed this elsewhere -- I should include a link to that discussion here.

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

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

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

• • 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?>

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

Line Wrapping

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

NEW 20010725: Initial Page Positioning

Konqueror 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?).

Mozilla

NEW 20030116: "--" Ends an HTML Comment

Oops, stop the presses -- it turns out this is not a bug but is in accordance with the actual definition of HTML comment markers. Mozilla gets it right, IE gets it wrong. Tom Kennedy sent me an explanation -- see it on MozillaBugWrongCommentMarker. The "simple" rule to follow is "An HTML comment begins with "<!--", ends with "-->" and does not contain "--" or ">" anywhere in the comment."

BTW: The FMs that I read (apparently not the canonical ones) stated that an HTML comment begins with "<!--" and ends with "-->" -- so my point is I R some of TFMs, but not the right ones.

("-->" should be required to end an HTML Comment)

I found this problem in Mozilla 1.1 (in Mandrake 9.0). It seems that if you start an HTML comment (using <!--), you can end the comment (inadvertently) if you include "--" within the comment.

I experienced this while editing Wikilearn.WebTopicEditTemplate and changing the text within the "boilerplate" search on that page (only seen while editing).

I'd like to rant here, I digressed from what I was doing for quite a while -- there's got to be a better way (I'll write more later) -- maybe need triage'ers for various software packages to triage bugs. (I dread trying to submit this to Mozilla, half expecting to be told that it's already fixed (that would be great) or that they won't accept the bug report because it's against an earlier version of the software). I want to write more later, so I'll start this page Wikilearn.BugTriagerPositions. (Among other things, need to isolate the bug -- is it in any way partly caused by TWiki?)

Reporting as Bugs

At least some of the behaviors listed above should be considered bugs in konqueror (or Mozilla, or whatever). 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? (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.)

See also the "rant" in the first Mozilla item.

Notes

Contributors:
-- RichardDonkin - 17 Jun 2001
-- RandyKramer - 19 Jun 2001 (rhk)

Refactored to incorporate comments from RichardDonkin and some general editing -- RandyKramer - 20 Jun 2001

<Add comments here or make appropriate changes to the text above, preferably with attribution of some sort if the changes are significant.>

<Attribution might be done by putting your initials in parenthesis and adding your name and initials to the list of contributors.>

I'm marking this as an answered question -- it isn't really so much a question as a statement of "facts", and it is "ongoing" -- others may be added as found. If someone feels it should be marked as an asked question, feel free to change it back. (Aside: I haven't yet downloaded and installed any more recent versions of konqueror to see if the behaviors listed above have changed -- probably won't for a while -- maybe when Mandrake 8.1 is released, if I can install it on my machine.

-- RandyKramer - 24 Sep 2001