Tags:
create new tag
view all tags

Implemented: added CssClassNames to Diff output

this is documented in CssClassNames.


RDiff colours are hardwired into rdiff

The background colours for the "deleted" "added" and "changed" lines are hardwired into the rdiff script. If you have a skin that changes the colours to a darker background and lighter text, the text becomes invisible on the default colour backgrounds.

Patch

--- twiki/bin/rdiff   2003-05-19 20:25:49.000000000 -0400
+++ twiki/bin/rdiff 2003-07-26 13:40:09.000000000 -0400
@@ -69,9 +69,13 @@
             $data = renderCellData( $data, $topic );
             $result .= $data;
             $data = "";
-            s/^([0-9\,]+)d([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#FFD7D7" colspan ="2"><b> Deleted: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
-            s/^([0-9\,]+)a([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#D0FFD0" colspan ="2"><b> Added:   <\/b><\/td><\/tr>\n<tr><td bgcolor="#40FF40" valign="top" width="1%">&gt;<br \/>&gt;<\/td><td>/go;
-            s/^([0-9\,]+)c([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#D0FFD0" colspan ="2"><b> Changed: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
+           my $delbg = &TWiki::Prefs::getPreferencesValue( "DIFFDELBG" ) || "#FFD7D7";
+           my $addbg = &TWiki::Prefs::getPreferencesValue( "DIFFADDBG" ) || "#D0FFD0";
+           my $changebg = &TWiki::Prefs::getPreferencesValue( "DIFFCHANGEBG" ) || "#D0FFD0";
+
+            s/^([0-9\,]+)d([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="$delbg" colspan ="2"><b> Deleted: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
+            s/^([0-9\,]+)a([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="$addbg" colspan ="2"><b> Added:   <\/b><\/td><\/tr>\n<tr><td bgcolor="#40FF40" valign="top" width="1%">&gt;<br \/>&gt;<\/td><td>/go;
+            s/^([0-9\,]+)c([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="$changebg" colspan ="2"><b> Changed: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
             $result .= $_;

         } elsif( /^[<>]/ ) {

Then add

  • Set DIFFDELBG=
  • Set DIFFADDBG
  • Set DIFFCHANGEBG=
to the appropriate preference page.

-- MalcolmJHarwood - 26 Jul 2003

This is a small worthwhile enhancement. I changed this bug report to FeatureEnhancementRequest.

-- PeterThoeny - 26 Jul 2003

If you defined one variable in terms of another, you have to wrap getPreferencesValue with TWiki::Func::expandCommonVariables(...). Is there a better way of doing that?

There seems to be a fair number of hard wired colours. I've been playing with templates and skins for a user's wiki and keep coming across things they can't change using preferences. It might be worth someone going through the default templates and converting them. (Most of my edits have been to a local skin, so they wont be much use to anyone else).

-- MalcolmJHarwood - 26 Jul 2003

I would suggest using CSS instead of hardwiring variable names. Thus skins can easily change these colors accordingly to their style. For instance, instead of:

   <td bgcolor="$delbg" colspan ="2">
use:
   <td class=diffdel colspan ="2">
And the skin would (re)define td.diffdel as it pleases in its CSS (e.g, td.diffdel {background:red} ).

Note that this method should be used for all colors and fonts used in TWiki... It is also faster on the server, as less variables are used, the work is done by the client, offloading the burden of the central server.

Also a skin can thus redefine the font and the ink color of diffs without to change anything more in the kernel...

-- ColasNahaboo - 28 Jul 2003

Why not just use TWikiVariables inside a template ? It's one of the reasons they're available after all. Yes it would mean that templates would have to allow people to specify a layout for diffs - but that should be the case anyway . In that situation people could choose different fonts, colours, etc for viewing changes, and at that point TWikiVariables are definitely the right approach.

Whilst style sheets are the "right" way to do things having something that falls back to older style browser is IMO more important. However that alone isn't a good explanation as to why I vehemently disagree that use CSS tags is how all twiki presentation should be done. Why? CSS values (especially when done sensibly with a stylesheet) cannot be changed by users - say a user who owns a Twiki web - they must be changed by the admin. Unless you have some form of skin editor that users can use who cannot logon to the system I'm unaware of ? (The closest fudge I've seen is allowing the location of the css file to be defined in a TWiki Variable so that when it's pulled in someone's entire view of the site changes.)

As a compromise however, I'd buy the idea of this however:

<td %BGCOLOUROLDREV% colspan ="2">
and...
<td %BGCOLOURNEWREV% colspan ="2">

That way you can use either (or both smile ) CSS and go from there. (I know the above code doesn't use this approach quite, but surely this should be template controlled rather than hardwired?) (And yes, preferably with english spelling)

-- MichaelSparks - 29 Jul 2003

Seems that Movable Type uses a CSS template (topic). Probably similar to FlexibleSkin (?). Are there any speed issues with MT that anyone knows of?

-- ArthurClemens - 29 Jul 2003

> CSS values (especially when done sensibly with a stylesheet) cannot be changed by users

The only reason CSS would only changeable by the Admin is because the site (or skin) is setup up that way[*]. It is easy to allow users to specify their own style sheets or rules. Style sheets are Cascaded, which means that they can be layered. The admin defines a master sheet for the whole site, then the users can layer their own sheet which changes only those particular rules they want to redefine.

[*] Not quite correct, any user can always setup User Stylesheet overrides for any website using their browser preferences (provided their browser allows for it).

-- MattWilkie - 29 Jul 2003

Sigh....

> any user can always setup

No. No. No.

Not all users have the ability to change their configuration. Not all browsers support CSS. Not all browsers support CSS correctly. Not all browsers are user configurable.

I stand corrected. I was referring only to CSS capable browsers but spoke as if to all browsers. I have amended my statement. --MHW

> The only reason CSS would only changeable by the Admin is

Really? So when did TWiki start serving out CSS files which allowed the CSS file to have (say) background colours, link colours, font sizes or similar defined in a preferences topic? Last time I looked this wasn't possible - after all TWiki always outputs HTML or RSS as the result of it's changes. (Not without pulling the stylesheet into the HTML of the page rather thank a link)

ummm, we are talking about twiki as it might be, not as it is at the moment.

(((and to be precise, one can pull in a linked stylesheet with twiki right now. I did this on twiki.org with Sandbox.SeeSkinDemo. It's just not very elegant and I wouldn't recommend doing this as a matter of course, but it works.))) --MHW

For example, if I have a nice backward compatible, table with a background colour defined in the template as %BGCOLOR% as the main table area then any user can override it. Any user, even one running a text browser, or a browser in a set top box, or running a system several years old which they can't upgrade, or a corporate user who can't change any settings on their computer. How do I do that using CSS at the moment? For all of those users?

Pragmatism and beats any form of idealism & social exclusion anyday.

Agreed --MHW

Until CSS is as configurable in TWiki as these "archaic" (though oddly backward & forward compatible, and quite frankly painless) methods then my opinion is that the default layout should be controlled using something everyone can change/use. Just my opinion of course. People tend to get carried away with how method "X" is correct, and method "Y" is wrong, without recognising that if you want collaboration you don't exclude people from collaborating by having a system that's ugly to people you've chosen to ignore as obsolete .

Many "lets use stylesheets only for layout/presentation" sites generally look absolutely terrible under anything that supports CSS poorly, or not at all. Not everyone has the luxury, ability, hardware capable of changing, or local access rights to change things.

I did not put forth argument this argument. I agree with your assessment. I was correcting an erroneous statement made with a voice of authority. This statement was the central point in your counter argument but was wrong so I couldn't let it pass unaltered. (And promptly committed the same sin in response!).

CSS values can be changed by users if the site is setup appropriately. I also point out that you said "many", not "all". It is very possible, though not always easy, to use CSS for those browsers that can, and html for those that can't, without resorting to browser sniffing and associated fragile trickery. --MHW

On a secondary note - the ONLY browsers that support CSS even vaguely correctly are also those that support javascript pretty well. If we decide to start using CSS everywhere for layout, presentation and so on we may as well start using javascript everyone and increase the minimum requirements for clients. This strikes me as a very bad route, and incredibly naive.

By all means use them exclusively in skins - (almost?) all skins if you like. However the default configuration should not rely on them.

I'll shut up now since this has gone off topic.

ditto.:) After a suitable interval this exchange can be moved to a topic where it belongs --MHW

-- MichaelSparks - 29 Jul 2003

comments inline, above, signed thus: -- MHW

-- MattWilkie - 30 Jul 2003

Well, the more I think of it, the more I think using TWiki variables for style is the wrong way.

  • Skinning do not work anymore. When changing skins, your solution would force also to set (a bunch of) TWiki vars, global for all users. Thus one could not use anymore the wiki-url?skin=XXX feature (e.g., skin=print).
  • Having different skins use different templates with different variables may work, but it will require a lot of different variables to be added per skin potentially used. And even then, it would not work easily for html not issued from a template, but generated from TWiki code like rdiffs
  • TWiki vars are upgrade hell, maintaining them through upgrades is a pain.
  • Not all browsers support CSS ... CSS is there, and has been there for a long time (longer than XHTML :-). Basic CSS (fonts, colors) works quite well across browsers, even the obsolete netscape 4. You seem to mix CSS1 & CSS2, CSS2 support is really only available partially, but CSS1 is there. And if not (lynx, mobile phones), the goal of CSS is to provide graceful degradation when not understood! All browsers support basic CSS1. Or show me one not displaying the KoalaSkin in a usable way.
  • I used this method in KoalaSkin: use positioning by tables, not CSS2, but use font & color info via CSS1. It works perfectly on all browsers.
  • Like Arthur described, KoalaSkin allows setting complementary CSS in TWiki vars, so you can still make it user-customizable. You can change values by adding other style declarations overriding the skin-defined ones.

-- ColasNahaboo - 30 Jul 2003

I agree with Colas. Additionally I am concerned that we will suffer from VariablesBecomingUnmanagable - with no way of structuring to reduce the number and complexity.

-- MartinCleaver - 31 Jul 2003

So all you do is trad a user changeable value for a non-user changeable value. (CN: On the opposite: having a CSS class allow the user to change much more than just was envisoned by the author)

If TWiki goes entirely CSS for layout & presentation (CN: I though I was clear that I advocated use of CSS for presentation, not layout) I'll probably stop using it (or the main distribution), and switch to something Python based anyway.

Colas's arguments to me seem self-contradicting: "On the one side you have skins that can be partially overridden by twiki variables, but using twiki variables to configure a skin is wrong," (to paraphrase). (CN: to clarify: you can do it if you want, but it is not the preferred mecanism, which is for KoalaSkin, all options in one topic that will be precompiled)

Also yes, CSS, has been around a very long time, and still not everything implements it correctly. (Mozilla for example can make a right hack of things which even netscape 4 doesn't botch, similarly I see (almost every day) pages which break Konqueror - not many, but enough due to their use of CSS.) (CN: Again, I tested Koalaskin use of CSS1 on netscape 4 and konqueror without problems, and the problems with NS4 are more with bugs in traditional table layout than CSS1)

Also, has Colas really tried his skin on all devices? Which mobile phones? Which set top boxes? (CN: Most of these devices use recent browsers, that are much more CSS1-capable than the old NS4 bloated with uneeded features. The mobiles are ruled by Nokia and Ericsson, that are part of psion/symbian, which uses the CSS king, opera - I use a psion PDA with opera -. And for set top boxes, if somebody sells a set top box not able to see sites that even NS4 can display, they are not going to have a lot of customers)

The default skin supplied with twiki should cater for as wide devices as possible. And by catering I mean "not suck" - which quite frankly most CSS based sites I've seen do. (Including the various CSS twiki skins I've seen). This includes browsers like lynx, mobiles and set top boxes. (Working well for text browsers also means you work well for people using braille based browsers, something people tend to forget, when they go all whizz-bang with fonts "because they can") (CN: CSS IS DESIGNED FROM THE START TO HELP BLIND PEOPLE AND NON STANDARD DEVICES. CSS is a way to get rid of the font tag. See the W3C guidelines for accessibility: http://www.w3.org/WAI/References/QuickTips/: Use CSS for layout and style where possible )

If however we require CSS, we should support Java 1.0/1.1 & Javascript. (No CSS browser that gets it right doesn't support the former 2 AFAIK) (CN: I say it once more in an other way: if a browser do not understand CSS, everything will be visible, since all the fonts will be the native ones for the platform: no risk to have dark text on dark background then, since this point is moot.)

-- MichaelSparks - 31 Jul 2003

Added my comments to Michael previous post (CN: like this) Michael, you definitely had horror stories with CSS (CSS2 I guess) that make you over-react and not consider the actual case in point. Try to look at the issues with a fresh eye...

-- ColasNahaboo - 31 Jul 2003

I'm in this code right now, and thought i would fix this - but after reading the topic i want to know what todays attitude on this is smile

do we have a plan from removing the hardwired colours yet?

-- SvenDowideit - 20 Mar 2004

The topic discussion above has mainly resulted in a CSS flame war. Common interests are:

  • Maintain a minimal compatibility with NS4 and other non-compliant browsers
  • Upgrade TWiki to CSS based layout wherever possible
  • Allow users or admins (not server admins) to change styles, colors

My approach would be:

  1. Just add (not replace) the CSS tags to bin/rdiff; the hardwired colors can be left for backwards compatibility, and in case CSS fails somehow
  2. Use dynamic topic includes for basic TWiki styles. For this
    1. I have created the TWiki.TWikiStyle topic
    2. In TWiki.TWikiPreferences, the new variable BASICSTYLETOPIC points to this topic
    3. In twiki.tmpl, add:

<style type="text/css" media="all">
      @import url("%RELATIVETOPICPATH{%BASICSTYLETOPIC%}%?raw=on&skin=text&contenttype=text/css");
</style>

  1. 4 In rdiff, use this:
sub renderRevisionDiff
{
    my( $text, $topic ) = @_;

    $text =~ s/\r//go;  # cut CR
    my $result = "<table width=\"100%\" cellspacing=\"0\">\n<tr><td>";
    my $data = "";
    foreach( split( /\n/, $text ) ) {
        if( /^[0-9]/ ) {
            $data = renderCellData( $data, $topic );
            $result .= $data;
            $data = "";
            s/^([0-9\,]+)d([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#FFD7D7" class="TWdiffdeletedheaderbg" colspan ="2"><b> Deleted: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" class="TWdiffdeletedbg" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
            s/^([0-9\,]+)a([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#D0FFD0" class="TWdiffaddedheaderbg" colspan ="2"><b> Added:   <\/b><\/td><\/tr>\n<tr><td bgcolor="#40FF40" class="TWdiffaddedbg" valign="top" width="1%">&gt;<br \/>&gt;<\/td><td>/go;
            s/^([0-9\,]+)c([0-9\,]+)/\n<\/td><\/tr>\n<tr><td bgcolor="#D0FFD0" class="TWdiffchangedheaderbg" colspan ="2"><b> Changed: <\/b><\/td><\/tr>\n<tr><td bgcolor="#FF4040" class="TWdiffchangedbg" valign="top" width="1%">&lt;<br \/>&lt;<\/td><td>/go;
            $result .= $_;

        } elsif( /^[<>]/ ) {
            s/^[<>] (.*)/$1/go;
            $data .= "\n$_";

        } elsif( /^--*/ ) {
            $data = renderCellData( $data, $topic );
            $result .= $data;
            $data = "";
            $result .= "\n</td></tr><tr><td bgcolor=\"#40FF40\" class=\"TWdiffaddedbg\" valign=\"top\" width=\"1%\">&gt;<br />&gt;</td><td>\n";
        }
    }
    $data = renderCellData( $data, $topic );
    $result .= $data;
    $data = "";
    $text = "$result<\/td><\/tr>\n<\/table>";

    return $text;
}

See a rough example on: http://www.dekko.nl/cgi-bin/extranet/rdiff/Sandbox/NewPatternTestPage?skin=newpattern

Note that the included style topic will be cached by the browser. Further style definition will be needed for the table layout. Eventually, the table may be replaced with divs.

-- ArthurClemens - 20 Mar 2004

until there is a decision I am using something like the baove, but with CamelCase smile

-- SvenDowideit - 26 Mar 2004

Documented in TWikiCss.


Just for the record, or if someone refactors this topic: BASICSTYLETOPIC was replaced by TWIKILAYOUTURL, TWIKISTYLEURL, USERLAYOUTURL and USERSTYLEURL.

-- ArthurClemens - 17 Aug 2004


Category: TWikiPatches
Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2004-08-17 - ArthurClemens
 
  • 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-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.