isColor()?

[Ry Nohryb]

On 2010-08-17 12:30 AM, Ry Nohryb wrote:
[...]

function isColor (color) {
   var dummyElement= document.createElement("span");
   try { //IEs throw for non valid colours... LOL

And yet again, as I carefully explained (please read it), for any
"unparsable" color, an error should be expected, as per DOM 2 Style.

I'm getting the broken record feeling again. Is the specification that
unpleasant to read? How, if at all, was the explanation I provided, not
clear? Or what??

"the broken record feeling", "unpleasant to read?", "Is it not
clear?", "Or what?" : Your idiotic attitude leaves much to desire,
Smith. Don't you see the try/catch/[finally] in there ?

Now it returns either a string value or undefined.

In IE5/Mac:

javascriptfunction (e){
try {e.style.color="k27"; } catch (err) { }
alert(typeof e.style.color);
})(document.createElement('span'))
--> "string"

ROTFLOL, does it give something !== in your Windozes PC ?

 

[Lasse Reichstein Nielsen]

No, I carefully and correctly explained what can be expected of the code.

You are correct that this is the expected behavior of the given code
on an implementation of the DOM that follow the spec to the letter.

I misunderstood your comment to be related to the intended behavior
of the code.

What it is *required* to do, by the DOM 2 Style standard that I
referenced, is to throw an error.

That is correct.

It is not what it was *intended* to do, though, so it's a fair guess
that the function actually throwing the exception is a bug in the
function.

What the author was expecting was probably that it would not throw an error.


You're following right into Jorge's faulty thinking.

I do believe I'm following his thinking to the point where I can guess
his intended behavior of the function.
Not its actual behavior on all browsers, but again, that's a bug in
the function.

No, it is not "broken in IE because IE behaves differently." The
function is broken by design. I see you've fallen into the trap of the
misthinking that since IE is different, it must be wrong.

Not at all. I never said that IE was wrong. I stated that the function
was broken, because it doesn't correctly handle the behavior of IE.

I carefully referenced DOM 2 Style specification and a couple of other
specs. You snipped that. Please do read that

I did.

I suggest reading reading my explanation carefully. After doing this,
please follow up on this thread to acknowledge that the answer I have
provided is correct. Otherwise, others may believe that you are
correct here (you're not).

Your answer is correct, but useless.
We have four out of five browsers not acting as your "expected" behavior.
That's quite relevant. There is one that does. That's relevant too.

The code should support both the actual behavior of known browsers
and the specification specified behavior (even if no current browser
had actually followed it).

Thank you.

Doing that would hide any exception and, as stated in the
specification, an exception required to be thrown.

It wouldn't *hide* the exception. It would *handle* the exception.
That's a completely reasonable thing to do with exceptions, and
why the catch syntax is in the language

An error is required to be thrown if the value has a syntax error and
is unparsable.

And it will be, at least in IE.
Then you catch it and return a result that signifies that the color
was unparsable.

And that would fix the function in IE to behave as intended.

I very carefully explained all of that in the message. You've not
acknowledged that and snipped what was written without comment.

I never disagreed with the DOM spec saying that an exeption should
be thrown, and that IE is correct in doing so, and that the function
was broken as written because it didn't handle that exception.

Now it does.

Right. Regardless, the approach itself is broken as stated for reasons
that I stated in my previous message and I fail to see what was wrong
with that explanation. Please do (re)read and acknowledge. TIA.

It was broken because it didn't handle the exception. Jorge has fixed
that. Now it appears to work.

Obviously I prefer my own, vastly more complex, solution
/L

 

[Garrett Smith]

You are correct that this is the expected behavior of the given code
on an implementation of the DOM that follow the spec to the letter.

I misunderstood your comment to be related to the intended behavior
of the code.

Thanks for clarifying.

That is correct.

It is not what it was *intended* to do, though, so it's a fair guess
that the function actually throwing the exception is a bug in the
function.

That function will fail with any browser that implements DOM 2 Style and
throws errors on unparsable values. SO far we've only seen that in MSIE.

[...]

Not at all. I never said that IE was wrong. I stated that the function
was broken, because it doesn't correctly handle the behavior of IE.

I can't agree with the thinking that the function is broken because it
doesn't correctly handle the behavior of IE.

Try to understand where I'm coming from here.

There is a specification stating that an error should be thrown. If IE
were to not throw an error, would you surmise that no browser throws an
error, or that it works in "all browsers" do? We didn't even test in
Blackberry -- but that's not the point.

The point is that before declaring a bug or "it works" or any expected
outcome, you must first have a clear understanding of reasonable
expectations for that function.

Those reasonable expectations are made by more than mere observations of
what happens in a few browsers. The specification is highly relevant
here because it helps get past the part of "what browsers do" to "what
browsers must do"; it is *not* useless.

I did.


Your answer is correct, but useless.

No, my answer is correct and relevant and useful.

I saw Jorge's strategy of developing a function based around what four
browsers do. I saw him blame the browser (IE in this case) that didn't
behave the same way. I saw the misconception that IE is wrong and then I
saw you echo that. I read that the function was "broken in IE because IE
behaves differently."

The function is not broken in IE because IE behaves differently.

The function is broken by design and approach. It is the design of: Try
[thing] in a small set of browsers, check the result, generalize and
deduce an assertion based upon said generalization. That is not a
logical way to go about making an assertion of expected outcome.

However, such assertion is what followed. And what followed was blaming
the one who acted differently. That one happened to be MSIE.

To quote Jorge in response to me claiming that his code was broken:

| In Microsoft's Internet Explorers... what's not broken in that piece
| of crap ?

Now on a deeper philosophical level, and existential level, I see this
sort of generalization fallacy being employed by humans.

I get the you're-not-right-you're-different a lot.

Now we have all these so-called minority groups for gays, blacks, jews,
etc, but what about the individual? Isn't that the smallest denomination
of humanity itself? Don't I have a group? No, I must not! I must not
think for myself. Nobody does that. That must be wrong!

[...]

I never disagreed with the DOM spec saying that an exeption should
be thrown, and that IE is correct in doing so, and that the function
was broken as written because it didn't handle that exception.

Now it does.

It avoids known errors in IE but more important, it is somewhat
future-proof against such errors.

We did not cover, however, disparity that may be seen in CSS3 system
colors or the keyword "inherit" or "currentColor", and so if the UI is
going to round-trip (user sends value to server, server sends value back
to any web client) then you could potentially see:

Firefox 4 ----> Server ----> IE6

Thus, if the user inputs "currentColor" in Firefox 4, and then returns
in IE6, he may see "" instead.


Firefox 4 --------> Server ---------> IE6 --> Server

"currentColor" --> "currentColor" --> "" ---> ""

Now the user won't see javascript errors because those errors are now
suppressed but he will get inconsistent results when the color value
that was set in Firefox is not in the safe subset of colors allowed by IE.

The post on this thread by rf pointed this out and touched upon such
issue. And provided the idea of creating your own color list. And my
early response about loving "papayawhip" and "cornflowerblue", if it
wasn't obvious, was a joke.

[...]

 

[Garrett Smith]

On 2010-08-17 12:30 AM, Ry Nohryb wrote:
[...]

function isColor (color) {
var dummyElement= document.createElement("span");
try { //IEs throw for non valid colours... LOL

And yet again, as I carefully explained (please read it), for any
"unparsable" color, an error should be expected, as per DOM 2 Style.

I'm getting the broken record feeling again. Is the specification that
unpleasant to read? How, if at all, was the explanation I provided, not
clear? Or what??

"the broken record feeling", "unpleasant to read?", "Is it not
clear?", "Or what?" : Your idiotic attitude leaves much to desire,
Smith. Don't you see the try/catch/[finally] in there ?

Jorge, I am sorry, but your expectations about how your original should
run were wrong. Your expectations of what the code must do appear to be
based on your observations of what four browsers did.

On the bright side, I see two "hearts" in your example in Firefox.

http://homepage.mac.com/jorgechamorro/cljs/103/

Do you see them? They're in the upper left and lower right corners.

In IE5/Mac:

javascriptfunction (e){
try {e.style.color="k27"; } catch (err) { }
alert(typeof e.style.color);
})(document.createElement('span'))
--> "string"

ROTFLOL, does it give something !== in your Windozes PC ?

That is a totally different function. Why would it return undefined? How
could it?

Again, please do carefully read the explanation provided.

 

[Thomas 'PointedEars' Lahn]

Dear comp.lang.javascript,

Dear poster (reads strange, doesn't it?),

I need to allow users to enter a color as free text (not by choosing
from a list) and I'd like to allow any color that will be recognized
by the user's browser.

That would be an accessibility and maintenance nightmare, considering that
users would mistype by accident or language habit (e.g. "grey" vs. "gray",
whereas only the latter is part of the standard), they would try color names
they know from real life but aren't always implemented (e.g. "lightgray"),
they would see the result only after they have typed the full name, it would
be language-dependent, and you would need to update for every major browser
whenever one is released. You really don't want to do this.

As Rob suggested, a palette or RGB color picker would be the best solution;
its controls could even be keyboard-accessible (few color pickers are).


PointedEars

 

[Ry Nohryb]

Jorge, I am sorry, but your expectations about how your original should
run were wrong. Your expectations of what the code must do appear to be
based on your observations of what four browsers did.

Yes, that's exactly what they were based on. It's now wrapped in a try/
catch, so it now works in IEs too. Not that I care even the slightest
about them, mind you, but yes, I agree, it's a good thing to know that
the specs say that this should throw.

On the bright side, I see two "hearts" in your example in Firefox.

http://homepage.mac.com/jorgechamorro/cljs/103/

Do you see them? They're in the upper left and lower right corners.

No. I have no idea what you're talking about.

That is a totally different function. Why would it return undefined? How
could it?

Given:

function isColor (color) {
var dummyElement= document.createElement("span");
try { //IEs throw for non valid colours... LOL
dummyElement.style.color= color;
} catch (e) { }
return dummyElement.style.color;
}

How can "return dummyElement.style.color;" return undefined ?

 

[Garrett Smith]

Yes, that's exactly what they were based on. It's now wrapped in a try/
catch, so it now works in IEs too. Not that I care even the slightest
about them, mind you, but yes, I agree, it's a good thing to know that
the specs say that this should throw.

The border in Firefox is dots but the dots near the corners don't quite
match the spacing and so Gecko elongates those dots that are near a
corner. In the upper left corner, the LHS of the dotted box is elongated
so that instead of being round, it looks like a pillar with a rounded
bottom.
| |
| |
\__/


This pillar overlaps with the top border, which looks a bit like:
____
\
____/

And they overlap like:

____
| \
| __/
| |
\__/

That's ugly there but it looks acually like a heart in Firefox.

[...]

Given:

function isColor (color) {
var dummyElement= document.createElement("span");
try { //IEs throw for non valid colours... LOL
dummyElement.style.color= color;
} catch (e) { }
return dummyElement.style.color;
}

How can "return dummyElement.style.color;" return undefined ?

Right, it can't. My mistake there, looking for a return value for the
catch and seeing nothing.

 

[Ry Nohryb]

On 17/08/10 22:39, Ry Nohryb wrote:
(...)

It shouldn't. But a function called "isColor" ought to return a boolean
value (IMHO). Use "return !!dummyElement.style.color", or else call it
validateColor() or something like that.

Aye, me bad. Yo-ho-ho.

 

[Ry Nohryb]

Right, it can't. My mistake there, looking for a return value for the
catch and seeing nothing.

function isColor (color, e) {
e= document.createElement("span");
try {e.style.color= color} catch (E) {} finally {return
e.style.color}
}

Why did Brendan put that "finally" thing in the language ?
Isn't it ~ completely useless ?
Was it in Java ?

 

[Michael Haufe (\TNO\)]

function isColor (color, e) {
 e= document.createElement("span");
 try {e.style.color= color} catch (E) {} finally {return
e.style.color}

}

Why did Brendan put that "finally" thing in the language ?
Isn't it ~ completely useless ?
Was it in Java ?

"finally" is useful in situations where cleanup should explicitly
occur regardless of an error. In system administration and ADO object
manipulations this construct is quite useful. The fact that it was in
Java no doubt had an influence.

 

[Ry Nohryb]

"finally" is useful in situations where cleanup should explicitly
occur regardless of an error. In system administration and ADO object
manipulations this construct is quite useful. The fact that it was in
Java no doubt had an influence.

Yes, yes, but any code that comes after the catch block is in effect a
"finally" anyways --> a "finally" block was unnecessary. Or not ?

try {
good();
} catch (error) {
bad();
}

//Any code here is === a "finally" block...

 

[Ry Nohryb]

Yes, yes, but any code that comes after the catch block is in effect a
"finally" anyways --> a "finally" block was unnecessary. Or not ?

try {
 good();

} catch (error) {
 bad();
}

//Any code here is === a "finally" block...

Ok, ok, ok. I've seen in your other post that this is similar but not
=== a "finally" block

 

[Michael Haufe (\TNO\)]

Yes, yes, but any code that comes after the catch block is in effect a
"finally" anyways --> a "finally" block was unnecessary. Or not ?

try {
 good();

} catch (error) {
 bad();
}

//Any code here is === a "finally" block...

Not necessarily, take for example this:

function doStuff(){
try{
throw "uh oh";
} catch(e){
logError(e);
iWasStupid()
} finally{
cleanUp();
}

WScript.Echo("Business As Usual");
}

function logError(e){
WScript.Echo(e);
}

function cleanUp(){
WScript.Echo("clean Up")
}

function iWasStupid(){
throw "durp";
}

try{
doStuff()
} catch(e){
WScript.Echo("something stupid")
}


If an error is thrown within the catch block, code following the
try...catch...finally will not execute.

 

[Ry Nohryb]

If an error is thrown within the catch block, code following the
try...catch...finally will not execute.

Yep. Thanks.

(function () {
try {
throw({once:1}); //once
} catch (e) {
throw({twice:2}); //twice
} finally {
alert("finally");
}
alert("post-finally");
})()

--> alerts only "finally" and *not* "post-finally", and returns an
unknown -at least to me- [object Object]. Why ? What's that returned
object ?

(tested in Safari, Chrome)

 

[Garrett Smith]

On Aug 20, 2:56 am, "Michael Haufe (\"TNO\")"
(function () {
try {
throw({once:1}); //once
} catch (e) {
throw({twice:2}); //twice
} finally {
alert("finally");
}
alert("post-finally");
})()

--> alerts only "finally" and *not* "post-finally", and returns an
unknown -at least to me- [object Object]. Why ? What's that returned
object ?

An object is thrown explicitly in the catch block.

 

[Ry Nohryb]

An object is thrown explicitly in the catch block.

Ah, yes, it's the result of that expression (which is *not* the return
value of that function) that happens to be the error thrown, right ?

(function () {
try {
throw Error("once");
} catch (e) {
throw Error("twice");
} finally {
alert("finally");
}
alert("post-finally");
})()

--> Error: twice

 

[Garrett Smith]

Ah, yes, it's the result of that expression (which is *not* the return
value of that function) that happens to be the error thrown, right ?

You got it.

 

[Lasse Reichstein Nielsen]

On Aug 19, 7:25 pm, "Michael Haufe (\"TNO\")"


Yes, yes, but any code that comes after the catch block is in effect a
"finally" anyways --> a "finally" block was unnecessary. Or not ?

try {
good();
} catch (error) {
bad();
}

//Any code here is === a "finally" block...

Other examples of when that's not true have been given when
the catch block terminates abruptly.
It is also a problem when the try block terminates abruptly
but not by throwing (returning, breaking or continuing)
try {
return 42; // or break or continue, inside suitable scope.
} catch (e) {
// nothing
} finally {
alert("always executed");
}
alert("not always executed");

Generally, the finally block is always executed.
Code after the try/catch/finally statement is only executed if
either the try block terminates normally, or the try block throws and the
catch block terminates normally, *and* the finally block terminates normally.
(Or one of them terminates by breaking from the the labeled try statement).

/L