As annoying as they can be, it'd be great if chatzilla supported color codes in the irc chat. They could simply be mapped to a span or something with the correct style. That makes it easy to turn off because you can just set the stylesheet to not change the colors. There is one small wrinkle though. I've seen two different types of color codes used, ANSI and whatever mirc uses. I'd have to do some research to figure out what mirc uses, though I do know that it's a much simpler system than ANSI. Yea, <span class="red"/> doesn't exactly jive with the spirit of css, but what can you do?

It's something I'd like to do, but I think it's more difficult than it sounds. In order to do it "easily", any colored text would probably have to ignore the rest of the transformation rules (link detection, bold, smiley, etc) <span class="red"> doesn't bother me too much, except I'd call it chatzilla-red, so you can tweak it in userContent.css without affecting other uses of the classname. I already use chatzilla-bold, italic, underline, etc. and don't feel too guilty :)

mIRC uses its own color system. Some other clients also support it to a certain extent (although I've seen cases where a client interprets them as the wrong colors), but there's no real standard other than what mIRC says it is. The spec for mIRC color codes is here: http://www.mirc.co.uk/help/color.txt

ircle has its own color codes too. most people would prefer for color codes to die.

Like it or not, color codes are here to stay. We have a few options: 1) Support color codes 2) Display color text but not allow Chatzilla users to use them. Expect a chorus of "Why can't I do that???" from users. 3) Strip color codes from incoming messages, and don't allow Chatzilla users to use them. Expect people to be confused when they see people talking about colored text, and are unable to see what they're talking about. 4) Go old-school and just display color codes as gibberish characters. Suffer in silence whenever text gets unreadable. I think #1 is the best bet, with an option to disable color. If it's implemented through CSS, disabling color codes would be as easy as commenting out the rules for "chatzilla-red" etc., without requiring extra prefs.

unless I miss my guess, it'd be fairly easy to have a item you could check on a menu in chatzilla for showing/hiding colors. Should just be able to apply different stylesheets to the chat window, and have color wither show up or not. You could even have a stylesheet that had disply: none; in the color classes, with the obvious effect. Might be a little drastic though.

Currently, ChatZilla does #4. If you're on a system that doesn't display unknown glyphs as a box, you might think you're getting #3. #3 is as far as I'm willing to commit to doing myself. Users be damned. While I think it'd be neat if ChatZilla supported color codes, I don't care enough about it to do an implementation. In fact, it's probably an option I'd leave turned off, personally. I'm leaving the bug valid, because it is, but setting it to a future enhancement because I'm not going to do it anytime soon. If someone is *serious* about doing the implementation, let me know and I'll help all I can. In the meantime, let's hold off discussion on how to go about it until there is someone to direct the comments to.

display: none would make all text between color codes disappear. I don't really think that's desired behavior. ;) If you don't want to work on it, why not just assign it to nobody@mozilla.org?

The patch adds support for interpreting color codes to the munger. I got the colors from xchat. Changes: chatzilla.xul - added a menu option to enable/disable handlers.js - code to handle the new menu option readprefs.js - code to save the setting static.js - code to initialize the menu checkbox - added a munger rule to find color codes - code to interpret and set the colors munger.js - code to create spans with classes corresponding to the colors output-default.css - classes for the colors

I have now added all control codes that I can find with xchat. I also added an option to either hide unknown control characters or display them. e.g. "\x05" would be displayed as "{^E}"

I changed the patch a bit, the munger rule names now look like the rest of them, and unknown charcodes now print as hex codes, the user can add deocrations before/after in css. We still have the word breaking problem, Hixie tells me mozilla works according to the spec there. <span>foo</span></span>bar</span> should not break because there is no space. Maybe we could count the number of consecutive color matches, and insert an image/reset the cound when it reaches client.MAX_WORD_DISPLAY

I just noticed two other things I forgot in the last patch. 1) in the munger, the new variable |textNode| isn't declared. 2) the indentation level the third line of handlers.js:onToggleControl is short by 1 space. The connection-xpcom.js change in my last patch shouldn't be there.

What's the word breaking problem? If you want <span>a</span><span>b</span> to be able to break between 'a' and 'b' then you want to insert a ZERO WIDTH SPACE which is character U+200B. This would look like this in markup: <span>a</span>&#x200B;<span>b</span> However, doing it from the DOM requires use of the DOM Core character entity reference creation. And then, of course, there is the potential problem that we may not support this -- if that is the case, please file a bug. :-)

*** Bug 82824 has been marked as a duplicate of this bug. ***

My last comments where misguided, as I had misunderstood the problem. I have since been told that the _actual_ problem is not to break words in particular places, but to break long words at the end of the content area. The solution is to use an extension to the CSS 'white-space' property. This bug is therefore dependent not on bug 79928 (U+200B fallback support) but on bug 99457 (white-space extensions).

Can we get just the "Strip color codes" part of this patch in for 0.8.5?

checked in to branch

Not sure if this is the right bug, but the mIRC colour munger seems to be missing the Control-C used to indicate the end of colours. So I can send some text that has a single word in colour, but Chatzilla renders then rest of the line in the same colour. It just seems to 'miss' the end Control-C code. Other than that, the mIRC colour munger is *really* useful.

James, that was fixed in recent versions of the beta. Try the latest one.

I'm using 0.8.5-pre19, which I *though* was the latest one. Correct me if I'm wrong, though.

yeah, pre19 is the latest, ssieb, did I miss something in the fix?

James, you're right, we didn't handle the plain ^C case to turn off color. Here's the patch, since I'm still using a build that apparently can't upload files. Index: static.js =================================================================== RCS file: /cvsroot/mozilla/extensions/irc/xul/content/static.js,v retrieving revision 1.30.6.25 diff -u -r1.30.6.25 static.js --- static.js 2001/11/19 04:25:41 1.30.6.25 +++ static.js 2001/11/25 23:12:37 @@ -363,7 +363,7 @@ "chatzilla-teletype"); obj.munger.addRule ("underline", /(?:\s|^)(\_[^_,.()]*\_)(?:[\s.,]|$)/, "chatzilla-underline"); - obj.munger.addRule (".mirc-colors", /(\x03(\d{1,2}|)(,\d{1,2}|))/, + obj.munger.addRule (".mirc-colors", /(\x03((\d{1,2})(,\d{1,2}|)|))/, mircChangeColor); obj.munger.addRule (".mirc-bold", /(\x02)/, mircToggleBold); obj.munger.addRule (".mirc-underline", /(\x1f)/, mircToggleUnder); @@ -545,6 +545,10 @@ fgColor &= 16; switch (fgColor.length) { + case 0: + delete data.currFgColor; + delete data.currBgColor; + return; case 1: data.currFgColor = "0" + fgColor; break; @@ -610,7 +614,7 @@ if (!client.enableColors) return; - var tempColor = data.currFgColor; + var tempColor = ("currFgColor" in data ? data.currFgColor : "01"); if (data.currBgColor) data.currFgColor = data.currBgColor; else

The chatzilla 0.8.5 branch has landed, if you believe this bug is not actually fixed, and you are sure you are running chatzilla 0.8.5-rc1, please reopen the bug for further consideration.