Bug: Font color problem (Improper tag nesting) in TWiki Preferences

[font] and [li]/[ul] tags are improperly nested in the TWikiPreferences page. This is malformed HTML and causes misrendering in some browsers (e.g. Apple Safari, perhaps also Konquerer since Safari and Konqueror share code). Specifically, the closing font tags in the color section of TWikiPreferences are not recognized (because of the improper tag nesting) and the font stays colored too long. For example, the entire final section of TWikiPreferences is rendered in a difficult to read yellow font.

konqueror 3.1.1 (Mandrake 9.1) does not seem to have this problem. (But I agree 100% with the next statement! (or XHTML)) -- RandyKramer - 05 Jun 2003

It would be nice if the TWikiPreferences page were modified to produce legal HTML.

Test case

Environment

TWiki version:	Beijing
TWiki plugins:
Server OS:
Web server:
Perl version:
Client OS:	Mac OS X
Web Browser:	Safari, perhaps others too

-- KevinWalker - 15 May 2003

Follow up

Part of TWiki's strength (and probably one of its biggest curses) is the ability to put HTML in any page. It is one of the reasons TWiki is being pushed far into other realms beyond what a WikiWiki was originally designed to do. Many things which were originally one person's "gee whiz" tricks using forms and %SEARCH%{} and some HTML glue have now come to be used by the rest of the TWiki community.

The "core" logic of TWiki generates reasonably good HTML (assuming you agree a given skin's templates HTML are okay - another subject in itself - even for the default template). But, in a few too many places, TWiki relies on the HTML skill of the administrator (and users). Thus, a great deal of what surrounds the "core" of TWiki still seems to be stuck in a pre-HTML 4.0 mentality - a time when using tables for everything, inline font and color, unclosed tags, etc. were the norm for the world wide web. And, although some of them look really exciting, even a few new realms I see TWiki exploring make me a little nervous in this regard.

There is a good amount of HTML within the TWiki topic pages themselves that without which, TWiki would not function very well. Also, there is considerable HTML generated by many plugins and skins that most users could not live without (and thus, should be considered part of the "core", IMHO). While coding mistakes will always be made, it would be nice if more of these areas' HTML quality were reviewed along with the TWiki core logic. (The ConsolidateFunctionalityFromSkins process is quite exciting.)

At best, the new realms TWiki users have now come to rely upon will become better integrated with the core. A given administrator or user previously relying on their HTML glue would (hopefully) then discard the HTML glue code completely and come to rely upon TWiki's ability to generate (hopefully) better HTML than they could craft by hand.

At the very least, maybe every template in every skin (especially the default skin) should include a link to the w3.org HTML+CSS verification script. This type of link on every generated page is a practice most other HTML generating tools are adopting (blogs, etc.) If TWiki had it, it would be a big reminder how much further the TWiki core + all its supporting topic pages + plugins + skins truly needs to travel on the road to XHTML 1.0 compliance and beyond.

-- TomKagan - 15 May 2003

Kevin, if you will look at page TWiki.TWikiPreferences in raw format, you'll see how color names are defined, using TWikiVariables and unclosed FONT tag (which is closed in ENDCOLOR variable). Problem is, variable definitions needs to start as list item, and it will "slurp" whole line, so we cannot put closing /FONT tag to color before next item is started.

To make variable definitions as colors 100% compliant, we need to enhance syntax for defining variable to allow limit what goes into variable value, like } here:

• SET VARIABLE = {this is value}this is not

And it still might not be 100%. There was a discussion somewhere that color text s/b defined like TEXT{"red" "my red text"}. I disliked proposed idea then (current implementation is much simpler), but as you pointed out, is not kosher.

-- PeterMasiar - 15 May 2003

Peter -

I did look at the raw source, and I was unable to think of an easy fix, for exactly the reasons you give. I submitted the bug report here because I thought more experienced people might think of a trick that I missed.

I think your proposed extension of the set-variable syntax is a good idea -- probably useful in other situations as well. Perhaps I'll have a look at the relevant perl code and see if I can come up with a patch.

-- KevinWalker - 16 May 2003

It seems to me that inserting the following code into the function prvAddToPrefsList of Prefs.pm would do the trick.

    if ($theValue =~ /^\s*\{\{(.*?)\}\}/) {
        $theValue = $1;
    }

This would allow

    * Set keyname = {{this is part of the value}} but this is not

I used '{{' instead of '{' because this choice seemed less likely to break existing pages (which might well contain '{...}' but are unlikely to contain '{{...}}' ). Of course other syntaxes are possible.

If one wanted to be fancier one could implement some sort of escape mechanism so the, e.g., '\{{' has no special meaning. I'm not sure whether this is worth the trouble.

I'd be interested to hear the opinions of the main TWiki developers on the above suggestion.

-- KevinWalker - 16 May 2003

I've implemented the above at my site. (Extended the Set syntax and changed the color section of the TWikiPreferences file to take advantage of the new syntax.) It seems to work well.

-- KevinWalker - 17 May 2003

Interesting idea with the {{...}} delimiter. There seems to be one "gotcha": Settings can span multiple lines, provided that the follow up lines have leading spaces. As in:

   * Set MORE_THEN_ONE_LINE = first line,
     second line with leading spaces,
     third line with leading spaces.
This is not part of the setting

Another workaround would be to put all color settings into <verbatim> text. The preferences settings do not care if they are in a <verbatim> block.

-- PeterThoeny - 17 May 2003

Since prvAddToPrefsList gets called individually for each line, in my current implementation

   * Set key = {{this is the first line of the value}} but this is not part of the first line
               {{this is the second line}} and this is not part of the second line
               it's ok to combine double brace and non double brace lines; this whole thing is long line number 3

On the other hand,

   * Set key = {{if the braces are on separate lines
               they are ignored}} this is still part of the value as are the braces

It would not be too hard to allow the braces to span lines. Another possibility is to use an inline comment style of comments

   * Set key = this is line 1  # but this is not part of line 1
               this is line 2
               this is line 3  # but this is not part of line 3

-- KevinWalker - 17 May 2003

Question: What about using CSS Style sheets instead of (partial : ) font tags?

-- VickiBrown - 05 Jun 2003

Fix record

I took the simple approach (one of TWiki's principle is KISS) using verbatim tags. Please let us know in case this does not solve the tag nesting issue.

-- PeterThoeny - 06 Jun 2003

The fix with verbatim tags looks fine on my browser (Apple Safari / KHTML)

-- KevinWalker - 14 Jun 2003