The Un-Official Proxomitron Forum

Full Version: REQ: Javascript Text Fader
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Function: To be able to fade a user specified string of text from one colour to another (black to white), or one colour to a different colour then back the to first color (black white black). [the black/white are examples...]

The user will be able to insert colour HEX codes and check off which output they want (black to white, or black to white to black).

The output should be
Code:
[color=#000000]H[/color][color=#FFFFFF]i[/color]

It would be wonderful if someone could write this javascript Pervert
N/m, I found what I was looking for, but now I can't seem to get the results [unsure]

Something about:

Code:
daw=window.open("","","")
dw=daw.document.write

Please help? Wink
N/m...LOL!

I fixed it, the second button had a messed up daw=window.open code.

But now how to make it support Mozilla/Opera....
Kye-U;

You asked for some help making this spagetti mess work in Mozilla/Opera. What I have to offer may not solve all your problems, but it should go along ways toward it. Here are my notes, and some comments:

Lines 18-20: Move the <br> tags outside of the [/url]

Lines 38-39: Same thing, except put them in front of the <A....

Line 45: Assigning a variable without the var statement is risky - some environments allow it, some don't. Use {var hexa = new Array()..... instead.

Now for a harsh critique.

First off, this code requires 309 lines, over a 120 of which I find redundant and wasteful - they could easily be re-coded into one function of maybe 30 or 35 lines, max. However, without actually trying it myself, I predict that I, or any other qualified coder, could probably fulfill your requirements in approximately 150 lines, give or take a dozen. What you asked for isn't so hard to accomplish.

Next, the main reason for all that gobbledy-* code is that the user is allowed to enter anything his/her little heart desires - not a good interface practice, and certainly not a good coding practice, as it leads to the requirement of all that conversion code. Instead, I'd simply give the user a list of choices with a SELECT/options statement. No further coding necessary, this tag has everything you need to do the job.

Finally, the results page is so ugly that I couldn't look at it for more than a few seconds. I had to drop a half a bottle of Visine in my eyes in order to stand the strain of looking at it, just to see if the page had actually done the job. It did, but gawd, is that thing ever UGLY! Bad berries, my young friend, very bad berries. Unless your requirements are such that a second page is necessary for the results, I would have simply appended the results to the bottom of the first page, not a hard thing to do in this day and age.

If this seems unduly harsh, then let me be the first to apologize, then let me be the first to also offer my time and effort to doing this correctly, meaning with elegance of both code and interface. It's your decision. Wink


Oddysey
Thanks for the reply Oddysey!

Here is the updated version, and I'd be glad to have you clean up the script Hail
I don't mind having the results pasted at the bottom of the screen either Wink

But 'd like the user to be able to insert their own colours and text.
Kye-U;
Quote:.... But I'd like the user to be able to insert their own
colours and text.
Please define "their own colors". This goes to the crux of all interface issues that designers face today - "How much freedom do we allow the user to exercise?"

Since I've been deprived of the most elegant method of ensuring that users will stay within bounds (the SELECT/options statement), I have to ask for further clarification on what constitutes acceptable input. And the page should inform the user of those limitations, if any.

Consider the following example. What if I enter a non-word, such as "MXYZPTLK"? That's not a valid color choice, but guess what? The current code not only allows and accepts that choice, but it does indeed translate it into a random color. For more fun and games, try entering "foobar", and then try "foo" and "bar" separately. See what I mean? This is the result of what I euphemistically call "irresponsible programming".

Additionally, we need to consider the following questions:

> Can the user enter only color names?
> How about color codes, ala HTML coding?
> What about the so-called "web-safe" colors - any limitations here?

And last but not least, I still have not seen anything suspicious regarding the lack of executability in Mozilla/Opera. But I did see something I missed the first time around Banging Head. Look at lines 37-42; these six lines have no semi-colons after them. That means that they are superflous, because they aren't executing as part of the overall script, and yet the code still executes as intended (at least on IE, anyway). It's little things like that that make it hard to track down glitches in browser interoperability. I don't see how this can affect one browser, and not another, but it's always worth considering.

In summary.... (Yeah, right - as if I could ever keep it short and sweet! :P) I'll need to install a fair amount of error-trapping code in order to make sure the user input is valid. (That is, unless you relent and allow me to implement a list box.) Please advise on what user input is considered acceptable, per the above questions. Thanks.


Oddysey
I'd like them to be able to enter hex values or color names.

Maybe work on displaying the results at the bottom of the page first :P

I hope that's the easier part Eyes Closed Smile
Kye-U;

Displaying stuff on a page after it has loaded is child's play for a CSS-1 enabled browser (meaning pretty much anything after 1998/1999). I was more interested in just how much error-checking code was needed. As I read your Mission Statement now, "color names" means any of the 8 colors in textual format, plus their modifiers (blue, dark blue, light blue, etc.). That, and the hex codes, are acceptable input - got it.

Now there's only one more issue, which came to me last night just after I had shut down the machine. [Argh!] That issue being, what about background colors? Currently, the code decrees "Thou Shalt Be Blue", and that's it. But many chosen colors don't go well with blue, so I'm wondering if we should mess around with that, or just let it be. As you are the Project Leader, you get to make that decision.

How soon do you need this? I've got some family business to take care of today (Sunday), so I won't be able to dig into it until early tomorrow morning. Shouldn't take too long, once I get going.


Oddysey
I think that a white background colour will be the best Eyes Closed Smile

Since you're the only one aiding me, the project date will be set as whatever is most convenient to you.

I do not mind waiting for you Smile! I am going on a trip to Quebec later on the 14th, for 3 days, then on the 19th, I have my surgery, then I won't be online for quite a while. (resting period, then physio, then school! Banging Head )

Thank You! Big Teeth
Kye-U;

As the Star Trek computer said, "Working....."

<span style='color:red'>EDIT:</span> But if anybody else wants to jump in, feel free!
[/edit]

Oddysey
Reference URL's