Or perhaps BetterColours.

See also: BetterMarkupInGeneral, BetterMarkup and BetterIndicators and of course TooUglyForNonTechnicalUsers

---

Highlight Text With Color

Motivation: make thingsa smoother for the user, make Twiki less "programmer-centric" and more "user-centric".

The Current Scheme

The current scheme for highlighting text in colour uses variables defined in TWikiPreferences such as

    * Set RED = <font color="red">

Problems

While this has the value of simplicity, it has a couple of major shortcomings.

First, see articles such as http://alis.isoc.org/web_ml/html/fontface.en.html. Not just for font-face but for all the other attributes of <FONT> as well except possibly "class". It has been depreciated in the HTML 4 and the XHTML standards. Do your own Google search and read the W3 web site.

Secondly it is very limiting. It only allows the set of colors defined in the site or web preferences (unless you have the user preferences plugin installed and then it raises the problem of compatibility between users).

Ideally, we would have a style sheet mechanism for this in a world were both structure and color were determined by the sking, such as SesSkin. But we're not there yet and unless the browser manufacturers and coders wake up such standrds as CSS2 adn CSS3 will be of mere academic interest.

Proposed Solution

So I propose a solution.

Colorization of in-line text via an explicit operator:

Example:

    Now is the time for all %COLOR(red "good")% men to come to the aid of the party.

would render as    &nbsp Now is the time for all good men to come to the aid of the part.

The first parameter is the colour, the second is the text to be colorized.

Extended Syntax

1. %COLOR(fg=red bg=yellow "good")%
   The foreground color and the background color can be set. Both or independently
   • %COLOR(bg=yellow "good")%
     sets only the background color
   • %COLOR(red "good)%
     the default is teh foreground
2. %COLOR(red)% some text in red %COLOR%
   for longer spans turn the color off explicitly.

Advantages

1. Any color can be used, not just those defined in the Preferences
   e.g. %COLOR(fg=mediumvioletred bg=lightgoldenreodyellow "Oh WOW!")%
2. Symbolic names as well as hex values can be used
   e.g. %COLOR(fg=#003333 bg=#999999 "That's dark cyan on medium gray")%
   And don't forget things like "gray75", "grey75", and the shortfroms such as "#00"
3. It offer a more "style-sheet friendly appraoch.

Implementation

Of course it could all be done by translating to

   <font color=....

but that doens't allow background. We'd have to use

   <font style="color: red">

But unless we are tagging a style to a stylesheet, this isn't a great idea either. We'd be better having the style sheet define colors by some symbolic value. What happens when you say %COLOR(fg=blue bg=linen "sample text")% when the We'd be better off with %EMPAHSIS(contast "sample text")%. See BetterMarkupInGeneral.

But ther is the <SPAN> tag. It is for "tag-less styles", to alter the apearance of only a portion of the tags content. So the generated string now looks like:

   Now is the time for all <span style="color: red">good</span> to come to the aid of the party.

There are advantages to this.

1. We can migrate to getitng rid of color and just using <span> -- see BetterMarkupInGeneral
2. We can have a post processor that merges nested spans.
3. We can convert the spans to classes classes in the style sheet implementation.

Deferment

I'm not going to do anything with this until the BeijingRelease is stabilized.

I'd like feedback on this, but read BetterMarkupInGeneral and BetterMarkup.

-- AntonAylward - 03 Jan 2003

Would this also be the correct place to consider colouring of other elements ?? One of the many trivialities I hit as a problem today, was replicating a table with coloured backgrounds (without using HTML, but instead the simple ||| markup).

It would be nice to have a consistent way for handling all colours.

-- MichaelKearns - 03 Jan 2003

Yes. Consistency in such things leads to a much more pleasant user interface and a in all probability much simpler code.

-- AntonAylward - 03 Jan 2003

Why not something like:

   Now is the time for all %C1% good %CE% men

where CE means Color End, and the colors 1,2,3... would be defined by the CSS of the current web?

(1,2,3, would be good for picking colors during discussions, but we could have colors with more symbolic names: Cok, Cbad, Cdanger, Cnew, Cold ...)

The implementation of Cxxx would thus be only a <span class=xxx>, and CE being </span>

-- ColasNahaboo - 06 Jan 2003

While I like the idea of sybolic names very much, there is one overriding concern and that is the clarity of the user interface. See TooUglyForNonTechnicalUsers. To me red on yellow might only be a standout, sort of like wiping a page with a highlighter, wheras to you it might be "Danger Will Robison!".

The %COLOR()% syntax may seem clunky and involve more shifts (eight in "%COLOR()%" compared with 7 in %Cred% %CE%), but this brings me back to my original objection to the abbreviations. Be it %RED% or %C1% or %Cxxx%, it has to be pre-defined in something like TWikiPreferences. The %COLOR()% syntax has no such requirement.

-- AntonAylward - 06 Jan 2003

No, it can be in the code, no need to have it defined in TWikiPreferences.

The code could match %C([a-z_0-9]+)% generically, and replace by <span class=$1> ...

-- ColasNahaboo - 07 Jan 2003

Oh neat. Great.

Or if you don't have a style sheet .... <span style="color: $1"> ...

Its still not all I want, but its a d**n sight better than the present set-ip! Is there still time to get it in the upcoming release?

Do we need an error catcher? I can always write %Coloroff% and send the browser off into the blue yonder. At least %REDISHBLUE% has a null operation!

-- AntonAylward - 07- Jan 2003