Tags:
create new tag
, view all tags
UPDATE: Refactoring stopped (not completed) — rather than agonize any more trying to get this page "perfected" I'll just leave it as is for now — it conveys the story:

  • TWiki looks worse in konqueror than in Mozilla or IE, because konqueror renders more vertical whitespace from TWiki HTML than either Mozilla or IE
  • the causes are multiple, the problem could be fixed by changes in konqueror behavior, by changes in TWiki behavior, (and it could be made universal by changes to Mozilla, IE, etc., behavior),
  • it can be partially solved by a stylesheet applied to TWiki, either in your local browser, or on the TWiki server (on the TWiki server, it would not affect the rendering in browsers other than konqueror, because, AFAICT, those other browsers already do what the stylesheet does (and more))
  • another part of the partial solution is discipline by editors in avoiding unnecessary vertical whitespace in TWiki raw files

The symptoms include:

  • If you include a single blank line between paragraphs (in the raw TWiki file), it is rendered as what looks like two blank lines (in konqueror, but not in Mozilla or IE)
  • If you include more than one blank line between paragraphs, or blank lines anywhere else in the raw TWiki file, they are rendered (in konqueror, but not in Mozilla or IE)

If TWiki is modified to address this problem, I have an RFE that could be addressed at the same time with (I believe) minimal additional effort. The RFE would be to provide the ability to single or double space list items without breaking the list continuity. This is discussed below.

If somebody expresses interest in modifying TWiki to address the problem, I will be happy to refactor this to whatever extent necessary to make the problem understandable for that person. A first attempt:

  • Mozilla and IE do not render multiple consecutive blank lines, konqueror does (Mozilla and IE may not even render a single blank line, i.e., the <p /> tag, but I am uncertain on this point.)
  • Mozilla and IE seem to have a built in stylesheet that forces spacing before and after a paragraph so that it appears to have a blank line separating consecutive paragraphs or a paragraph and something else (I'm not as sure of this as I am of some of the other statements here — I'm at least a little confused on this point)
  • TWiki emits a blank line (paragraph — <p />) for most blank lines in the raw text file, but does not surround emitted paragraphs with <p> </p> tag pairs

My recommended solution for TWiki is to change its behavior to surround emitted paragraphs with <p> </p> tag pairs, and not emit a blank line (paragraph — <p />) for most blank lines in the raw text file. In other words, in most cases "extra" vertical white space in a TWiki raw text file should be ignored.

In saying the above, I recognize a single blank line as the TWiki markup for ending a paragraph, but it should not emit a <p />, but should instead add the closing </p> tag to the paragraph just ended, and if the next line is not something special (heading, list item, table, ...), it should emit the starting <p> tag for the next paragraph.

The one (or few) exceptions to this should be with respect to list items (and perhaps a few similar things, like headings (but I'm not 100% sure about what that list of similar things should include)).

The objective (of the exception) is to have a way to have list items rendered either single or double spaced, without breaking the continuity of the list. (single spaced = no blank lines between them, double spaced = a single blank line between them)

Symptoms of loss of continuity of the list are a restart in numbering or the multiple bullets on the same line symptom for list items "lower" than "level 1".

I propose that a single blank line between list items be the TWiki markup to cause a single blank line to be included in the rendered list, again, without causing the continuity of the list to be lost.

The mechanism for rendering the single blank line without breaking the continuity of the list would (could) be adding a pair of line break tags (<br /><br />) at the beginning of a list item to be double spaced (in other words, at the end of the previous list item, before the line break (\n) separating the two items).

Aside: I do have a local stylesheet that partially solves the first problem (symptom) for me. (In other words: it reduces the excessive white space between paragraphs separated by a single blank line, it does not do anything to reduce the rendering of multiple blank lines, nor does it address my desire to allow single or double spacing of list items without breaking the list continuity — I can address those last two by careful editing).

The basic approach of the stylesheet is to set the top and bottom margin, border, and padding to zero for most elements (H1, ..., H6, UL, OL, ...) but not for paragraphs (P). I'm using a top and bottom margin of 10 pixels currently which works well with the my preferred font selection (Courier).

The stylesheet does change the appearance, for the worse, for a few non-TWiki pages that I've seen, but not drastically so. The stylesheet continues to evolve (occasionally) as I recognize additional elements that need the top and bottom margin, border, and padding set to zero.

At any time, if someone requests the stylesheet, I'll pull my current version, dress it up (slightly) and attach it to this or some other page. What might now be called interim versions of the stylesheet exist on KonquerorVerticalWhitespaceProblemResolution.

-- RandyKramer - 22 Jun 2003

Hmm, maybe the above is a (partial) refactoring in some sense (or, at least, a refactoring of the summary)?

An older version of the page, partially refactored, remains below:


Refactoring in Progress — for the old page see revision 1.12

TWiki looks different (IMHO, worse) in Konqueror than in Mozilla (1.3) or IE (5.5) because Konqueror renders more vertical whitespace than either of those browsers.

I haven't tested other browsers, like Opera, but feedback on some other browsers would be helpful — is konqueror the only browser with this problem?

See also:

With respect to MozillaNotStylingXHTML, I'm unclear about a few things. What difference does that cause in the appearance of TWiki pages in Mozilla vs. IE 6? (Was there a change in IE 6?) For me, TWiki pages appear almost identical (at least with respect to vertical whitespace) in Mozilla 1.3 and IE 5.5 — konqueror is the odd man out. I don't know how to reconcile that with what it says on MozillaNotStylingXHTML — maybe I have to let it percolate a little more.

Contents

New Page

Summary is the Table of Contents

You can get a pretty good summary of this page by viewing the table of contents which is an outline of the page.

Excessive Vertical Whitespace in Konqueror

TWiki looks different (IMHO, worse) in Konqueror than in Mozilla (1.3) or IE (5.5) because Konqueror renders more vertical whitespace than either of those browsers.

Three Causes

TWiki Does Not Enclose Paragraphs in <p> </p> Tag Pairs

TWiki emits <p /> tags to separate paragraphs, rather than enclosing paragraphs in pairs of <p> </p> tags, which I think would be more correct.

Konqueror Renders Multiple Consecutive <p /> Tags, IE and Mozilla Do Not

Mozilla and IE:

  • will not render extra blank lines for multiple consecutive <p /> tags
  • IIUC, in some places, will not even render a single blank line for a single <p /> tag (see below)

I'm still mixed up on the second point — there are places where Mozilla and IE seem to render a single blank line for a <p /> tag and places where they do not.

Places where they do / might:

  • Between consecutive paragraphs
  • Between list bullet items

Places where they do not:

  • Between a heading and a paragraph (or a paragraph and a heading) — whether I include a blank line between the heading and paragraph in the raw text or not, the rendered version in Mozilla and IE look the same (in Konqueror the rendered space is larger if I include a blank line)
  • Between a paragraph and a list item (or vice versa) — similar note as above
  • Between a heading and a list item (or vice versa) — similar note as above
  • Between two consecutive headings — similar note as above

My guess is that the blank vertical space in the above 4 cases is rendered in Mozilla and IE as a result of the top and bottom margin, border, and padding parameters for those HTML elements. (I'm not sure where those top and bottom margin, border, and padding parameters are specified, whether in some explicit or implicit (virtual?) stylesheet.)

In Konqueror every <p /> tag is rendered as a blank line.

For a quick demonstration insert a string of <p /> tags in an HTML file and view it in each browser, in konqueror you will see multiple blank lines and in Mozilla and IE you will see, at most, one blank line.

TWiki Emits Many <p /> Tags

I mention this to point out another potential solution to the problem. TWiki's behavior is clearly the same regardless of which browser is used, but if TWiki did not output multiple consecutive <p /> tags it provides another way around the problem.

In particular, TWiki emits <p /> tags:

  • between paragraphs
  • (almost?) anywhere there is one or more blank lines in the TWiki "raw" text file

The only place the <p /> tags serve a functional purpose (specifically for IE and Mozilla) is:

  • to separate consecutive paragraphs
  • to cause lists to be double spaced instead of single spaced. (But, this is not a proper solution, because lists double spaced in such manner are not recognized as continuous lists — if you are using numbered list items, each will be numbered 1 (unless you manually number them) because each item is treated as the start of a new list. Similarly, such discontinuous bullet lists show up with multiple bullets on the same line, like:)

      • a list item with multiple bullets on the same line because it is not recognized as part of a continuous list

All other vertical whitespace (specifically in Mozilla and IE) is created by the top and bottom margin, border, and padding settings of the (X)HTML elements.

As a specific example of where blank lines do not show up in Mozilla and IE, whether you separate a heading from preceding and succeeding paragraphs by zero, one, or multiple blank lines, the page is rendered with the equivalent of one blank line between the heading and preceding or succeeding paragraphs.

For example, if the TWiki raw text file includes:

A short paragraph.

Another short paragraph.
---++ Heading

   * List Element

The emitted (X)HTML looks like:

A short paragraph.
<p />
Another short paragraph.
<p />
<h2> Heading</h2>
<p />
<ul>
<li> List Element
</li>
</ul>

Potential Workarounds or Solutions

User Avoid Whitespace in Raw TWiki File (unacceptable)

This is not an acceptable solution for me for two reasons:

I. I Want Whitespace for Editability

I want that extra whitespace in the raw file for editability. It's the difference (in the raw text file) between something like this (do you see the heading?):

If you are using numbered list items, each will be numbered 1
(unless you manually number them) because each item is treated
as the start of a new list)

All other vertical whitespace (specifically in Mozilla and IE)
is created by the top and bottom margin, border, and padding 
settings of the (X)HTML elements.
---+++ Konqueror Renders all &lt;p /> Tags, IE and Mozilla Do Not
Mozilla and IE will not render a blank line for more than one
consecutive &lt;p /> tag in any case

Mozilla and IE, IIUC, will usually not even render a single blank
line for a single &lt;p /> tag  (my best guess is that the blank
line between consecutive paragraphs in Mozilla and IE is rendered
as a result of the top and bottom margin, border, and padding 
settings in the their "default stylesheets" (which may be "virtual).

And something like this:

If you are using numbered list items, each will be numbered 1 
(unless you manually number them) because each item is treated
as the start of a new list)

All other vertical whitespace (specifically in Mozilla and IE)
is created by the top and bottom margin, border, and padding 
settings of the (X)HTML elements.

---+++ Konqueror Renders all &lt;p /> Tags, IE and Mozilla Do Not

Mozilla and IE will not render a blank line for more than one
consecutive &lt;p /> tag in any case

Mozilla and IE, IIUC, will usually not even render a single blank
line for a single &lt;p /> tag  (my best guess is that the blank
line between consecutive paragraphs in Mozilla and IE is rendered
as a result of the top and bottom margin, border, and padding 
settings in the their "default stylesheets" (which may be "virtual).

II. Users with Other Browsers Won't Minimize Whitespace

Users of Mozilla and IE (and other browsers that behave the same way) will not be conscious of or care about excess whitespace that they put in either for editability or by accident.

TWiki Remove Excess Whitespace from "Raw" File (not preferred)

Longer statement (to overcome cryptic heading): Provide a function in TWiki to automatically remove excess whitespace when saving the raw TWiki file.

The problems with this solution include:

  • This loses the editability of the raw text file, unless a mechanism is provided to reintroduce (arbitrary) excess white space when the file is opened for editing. By arbitrary, I mean the mechanism can follow certain rules rather than trying to recreate the whitespace someone left in the file the last time it was edited.

  • Not really a problem — ignore this: There are some instances where I want a list single spaced, others when I want a list double spaced (possibly both cases within the same TWiki file). But, inserting <p /> tags (or empty <p>[&nbsp;]

    pairs) is not the right solution because it breaks the continuity of the list (numbering, for example).

Whatever long term solution is developed should allow for single or double spacing between list items, preferably with a TWiki markup.

As noted above, as far as rendering, the <p /> tag is not the proper solution to this as it breaks the continuity of the list (numbering) — AFAIK now, the right solution would be the addition of
tags.

Local Stylesheet for Konqueror (acceptable workaround)

I'm using it now. wink

Works OK — makes spacing between paragraphs, headings and paragraphs, list items, headings and list items, list items and paragraphs look like Mozilla and IE in most cases. Exceptions:

  • konqueror shows multiple blank lines if they exist in the TWiki text file
  • (double check this) Mozilla and IE always include a blank line (so to speak) between consecutive headings, with this stylesheet and konqueror I can choose between one or no blank lines

The basic approach of the stylesheet is to set the top and bottom margin, border, and padding to zero for most elements (H1, ..., H6, UL, OL, ...) but not for paragraphs (P). I'm using a top and bottom margin of 10 pixels currently which works well with the my preferred font selection (Courier). Maybe it needs to be expressed in some other unit (percentage??).

It does change the appearance for a few non-TWiki pages that I've seen, for the worse, but not drastically so.

Aside (re application of a stylesheet): I also like to set a background color for the entire page (to deal with websites with backgrounds that make reading difficult) — unfortunately, the table heading text is an unreadable light yellow if I do this, and I can't override the text color (for the th element) in a stylesheet because:

  • the table font and background colors are "hardwired" in the table HTML generation sequence (somewhere)
  • setting all text to black solves this specific problem, but causes another — it loses the color distinctions for links, including visited vs. unvisited links.

Stylesheet on TWiki Server (probably acceptable workaround)

The same stylesheet I use locally could be installed on the TWiki server. In the testing I've done so far, the styles have had no negative impact on viewing with Mozilla or IE. Try viewing Wikilearn.KonquerorVerticalWhitespaceTestPage.

As noted above, it does change the appearance for a few non-TWiki pages that I've seen, for the worse, but not drastically so. But, installed on a TWiki server, it won't affect non-TWiki pages.

What about other browsers? More testing is required.

<old statement(s) for deletion after one more review> I don't know enough to know whether we can make a stylesheet that is only applied for specific browsers, if so, we could make it apply only when a TWiki page is read by konqueror.

I want to read up on skins and plugins — maybe a CSS stylesheet is all or part of what a skin is, and maybe I should consider trying to incorporate the stylesheet in a skin.

Get Konqueror to Behave Like Mozilla and IE

Probably harder than some of the other solutions, because:

Konqueror Behavior May Not Be Wrong?

It's not clear that the konqueror behavior is wrong — IIUC, the <p /> tag is deprecated, and the rendering is unspecified.

Konqueror Not Easily Changed?

I'm not capable of making a change anytime soon, and I'm not sure the konqueror developers would make or accept such a change, partly for the other reasons cited here.

What about Opera, etc., etc.?

If any other browsers have the same problem, changing konqueror will not solve the problem for them.

Change TWiki's (X)HTML

In either case, if I were making a change (and had to invest the effort necessary to figure out where and how to make the changes), there are other changes I'd consider making at the same time. See _

Alt. 1 (not preferred)

Not fully defined, but, along the lines of getting TWiki to:

  1. change all <p /> tags to <p> &nbsp; <p> tag sets (so Mozilla and IE render things just as ugly as konqueror)
  2. never emit consecutive <p> &nbsp; <p> tag sets

Alt. 2 (preferred)

Revise TWiki to eliminate all <p /> tags and surround all paragraphs with <p> and </p> tags. In my (limited) experiments, it seems that konqueror, Mozilla, and IE render the pages about the same in that case. Then, if necessary, do final adjustments with a stylesheet.

The goal: whitespace on the rendered TWiki page should depend only on the TWiki (and HTML) markup in the raw TWiki file, and not in any way vary based on added whitespace that might be included in the raw TWiki file for readability by the editors.

The one exception: a blank line between two paragraphs will be the TWiki markup to separate two paragraphs. It will be converted to (X)HTML as </p><p>, and a blank line between paragraphs will be achieved by use of a stylesheet with appropriate top and bottom margins. (If that cannot be achieved, we might have to convert the blank line to </p><p> &nbsp; </p><p>, or to <br /><
</p><p>.)

Possible additional exceptions:

  • A blank line separating items in a list might be the TWiki markup to render the list double spaced. It will be converted to (X)HTML something like <br /><
    (or whatever the most proper (X)HTML is.
  • A blank line separating two consecutive headings might be the TWiki markup to render leave a blank space between the two headings. It will be converted to (X)HTML something like <br /><
    (or whatever the most proper (X)HTML is.

And, just by coincidence, the rendered version of a paragraph will typically include a blank line after the paragraph (or top or bottom margin, border, or padding space that gives the appearance of a blank line).

<I'll pause my refactoring here, and start deleting portions of the old page.>

Notes for a TWiki Rewrite — Move Elsewhere

  • Add TWiki markup to choose between single and double spaced lists while preserving continuity (for numbering of ordered lists and to attempt to avoid multiple bullets on a single line for unordered lists)
  • Add a TWiki markup for the em dash "—"

Contributors

Old Comments

My opinion is that blank lines surrounding headings should not produce empty paragraphs. I, too, like to put them in for ease in reading the edit/raw text. Also, I don't think multiple blank lines separating paragraphs should produce n-1 (empty) paragraphs. No matter how many blank lines occur, they should simply serve to terminate the previous paragraph. If you really need to introduce extra vertical space in the rendered output, then either use CSS or explicit HTML. All just IMHO, of course...

-- DavidBright - 20 May 2003

Randy, the "<p />" rendering is invalid markup. Many browsers will accept it, though. Empty paragraphs are correctly marked up as "<p></p>". But, just to throw a monkey wrench into your plans, a browser implementation has the option to throw out all empty blocks completely. Repetitive "<p></p>" markup can also be legitimately colapsed down to null. All attempts at spacing would then be governed by the style applied to the previous/next blocks. I haven't come across a browser yet which handles it this way, though.

To control the gap between two HTML blocks and follow the spec, you need to apply style to the previous/next blocks. Alternatively, you can apply style to a non empty block (eg: implicit spacing: "<p>&nbsp;</p>", explicit: "<p>class="smallgap">&nbsp;</p>"). Anything else relies on the quirks of the browser.

-- TomKagan - 20 May 2003

<after a long followup / on and offtopic digression by me>

"It's not a bug, it's a feature." "<p />" is invalid markup as per HTML4.0 and XHTML1.0/1.1 specs. But, what Konqueror or any other browser does with invalid markup is, for the most part, undefined. There is no reason to rely on a quirk of a browser parsing invalid HTML when changing it to the valid HTML fragment: "<p></p>" will produce the same result and is pre-HTML4.0 compatible to boot! However, "<p></p>" is still a null HTML block with its attending parsing quirk, but browsers seem to agree on handling it the same way. Still, to create a block the HTML spec mandates a browser must parse and apply style, the block cannot be null. So, "<p>&nbsp;</p>" is the way to go.

-- TomKagan - 23 May 2003

To make this very long story short, there is already a bug filed for this, MozillaNotStylingXHTML. Should be fixed.

-- PeterThoeny - 24 May 2003

<hold:> Deleted and incorporated above, with additions to the Contributors list.

New Comments

Old Page

<the old page, to be deleted gradually as refactoring proceeds> Well, calling it a resolution is an exaggeration, but I feel like I made some progress in understanding the cause of the problem.

Side Issue: Attachment Table Renders Slowly

Move to another page

When an attachment table is included on a page (and not hidden), the page takes a significantly longer time to download, and I can see that the delay occurs as the attachment table is rendered. (In particular, the table heading.) I'm going to start making it a practice on WikiLearn to hide those tables (and leave a note there that says something like "Files are attached to this page (and links are embedded in the text above). The attachment table is hidden to reduce page download and rendering time. To view the attachment table, click "Attach", below."_

And, I may start a new topic to record and consider the issue — why does the heading take so long to download and render? Is it perhaps transmitting the heading as a graphic image (i.e., bitmap)? The reason that question arises is that on the Preview page, the background text word "Preview" is hidden by the table rendering over the background. Maybe the page title on Wikilearn should be Wikilearn.Attachment Table Slow Rendering.

Discussion/Comments

Aside: The separator between a paragraph and a heading, the separator between adjacent (consecutive) headings, and the separator between a heading and a paragraph are three different entities that can have different values.

Aside: Without knowing very much about Perl, IIRC, there is a certain kind of "line orientation" to it — at least some commands (regular expressions) work on a line of input at a time unless you do some extra gymnastics. Does the fact that TWiki is written in Perl influence the willingness to address some issues in what might be considered an ideal fashion? Something (for me) to think about and be aware of.

I'd like the rendering of TWiki pages to be as good as that from any available word processor, including perhaps exceeding the limitations of HTML. (For example, I'd like two (horizontal) spaces after the punctuation at the end of a sentence.)

<refactoring stopped here again (even though not complete above — need to think about the following:>

While I'm thinking about whitespace, (at least) one other point should be addressed. IIRC, it seems that the diff function in TWiki will detect a change in whitespace and treat it as a revision, even if it doesn't change the appearance of the rendered TWiki page. (I tried to prove that to myself once, not sure I did — there are some pages like VerticalWhitespaceChangeTestPage and HorizontalWhitespaceChangeTestPage on which I intended to test it.) Whether I proved it or not, or whether it's true at the present time or not, my point is that it would be incorrect behavior if it did that (and if anything as strange as a rewrite of TWiki occurred, it should be handled properly.

OK, what is proper? (I wish you hadn't asked.) Hmm, two things I don't want:

  • I don't want a meaningless change in whitespace to show up as a revision to a TWiki page.
  • I don't want to use a scheme of saving "normalized" raw text of TWiki which might result in addition or deletion of whitespace I add during editing for my convenience. (Forexample, I wouldn't want TWiki to delete extra vertical whitespace I might insert to set off headings in the edit window.)

So, what alternatives exist:

  • Do diffs (and base detected changes on) the rendered HTML — I was worried about this option at first, concerned that I'd see a lot of HTML tags or something in the diff. I'm not as sure of that right now (but I'm not sure I won't either) — this alternative seems worth exploring a little further.
  • Store a "normalized" raw text file — don't like this, see above
  • Store raw text, but "normalize" it before doing a diff — possible also, need to define what I mean by normalize -- would that mean delete all white space, or all white space that was not considered TWiki markup. (For example, a single blank line between paragraphs is TWiki markup, and at least so far, my premise has been that anywhere else it is not. (I'm hedging a little now, because the addition of a single blank line between list items (or before or after headings) could be treated as TWiki markup to distinguish between, for example single spaced and double spaced lists.)

(This leads to a single blank line (<cr><lf> or whatever) being TWiki markup in some situations, and others not, and multiple blank lines never being significant. (This is somewhat analogous to what the situation might become for horizontal spaces — a single space is alway significant, a double space (after a ., !, or ? (and :?)) is significant, any additional spaces are filler that the TWiki author may wish to include for his convenience. Oops, forgot about leading spaces for items and so forth. But, I think I know what I'm trying to say.)

I won't come to any conclusions right now, and clearly, if someone undertakes to rewrite TWiki, they should review the existing TWiki code to see how it is done.

(Because two dashes "--" is considered the HTML comment delimiter — you get strange results if you comment out a section of TWiki text that includes "--".) This is because, although it is sometimes (often?) stated that the HTML comment delimiters are <!-- and -->, that is not precisely correct. It is more correct to say that <! and > are the HTML command delimiters (??) and "--" (and "--") are the HTML comment delimiters, which are only valid inside an HTML command._

Brainstorming for a TWiki markup for the —

  • \-- or /--
  • ==

(Hmm, and while we're at it, it would be helpful to have TWiki markup for the < and > — could they be as simple as \< and \>? (Or /< and />?))

I did find two more anomalies in the course of what I did:

  • TWiki anomaly: See Wikilearn.KonquerorVerticalWhitespaceTestPage and view the hidden attachment table. When I uploaded the files I included HTML entities to show "<p />" in the comments, and they were visible. Today I looked at the table and they are gone. (Must have been some sort of save / render cycle kind of thing.

  • In the particular font I'm using in konqueror, H1 and H2, and H5 and H6 are the same size (no wonder I've had trouble telling the difference).

-- RandyKramer - 22 May 2003

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2003-06-23 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.