backgroundColor

if i change the backgroundColor of a tag to 'red',
it works in both ie and mozilla.
if i change the backgroundColor of a tag to 'redd',
i get 'invalid property value' in ie, and no error in mozilla.
go figure.

re: backgroundColor

cosmic foo wrote:[color=blue]
> if i change the backgroundColor of a tag to 'red',
> it works in both ie and mozilla.
> if i change the backgroundColor of a tag to 'redd',
> i get 'invalid property value' in ie, and no error in mozilla.
> go figure.[/color]

If I set background-color to "foobar", it doesn't work in neither
browser!. Even more strange: changing "foobar" to "eggog" doesn't
help!?

re: backgroundColor

cosmic foo wrote:[color=blue]
> if i change the backgroundColor of a tag to 'red',
> it works in both ie and mozilla.
> if i change the backgroundColor of a tag to 'redd',
> i get 'invalid property value' in ie, and no error
> in mozilla. go figure.[/color]

The CSS specification requires that unknown/unrecognised properties and
value be ignored. This is generally a good idea as it allows newer
features to be added and not cause problems for older implementations.

IE is in error for complaining instead of ignoring, but that is hardly a
surprise where IE's handling of CSS is concerned.

Richard.

re: backgroundColor

cosmic foo wrote:[color=blue]
> if i change the backgroundColor of a tag to 'red',
> it works in both ie and mozilla.
> if i change the backgroundColor of a tag to 'redd',
> i get 'invalid property value' in ie, and no error in mozilla.
> go figure.[/color]

and if you write

<p style="backgroundColor='red'">
insteed of
<p style="backgroundColor:'red'">
IE will do it
and Mozilla no

:-)




--
Stephane Moriaux et son [moins] vieux Mac

re: backgroundColor

VK wrote:
[...][color=blue]
> If I set background-color to "foobar", it doesn't work in neither
> browser!. Even more strange: changing "foobar" to "eggog" doesn't
> help!?[/color]

Try 'eggnog' and maybe the waiter will get you one ;-)



--
Rob

re: backgroundColor

RobG wrote:[color=blue]
> VK wrote:
> [...][color=green]
> > If I set background-color to "foobar", it doesn't work in neither
> > browser!. Even more strange: changing "foobar" to "eggog" doesn't
> > help!?[/color]
>
> Try 'eggnog' and maybe the waiter will get you one ;-)[/color]

I've tried 'beer' and my browser started drooling 8-0

re: backgroundColor

> if i change the backgroundColor of a tag to 'redd',[color=blue]
> i get 'invalid property value' in ie, and no error in mozilla.
> go figure.[/color]

The main JavaScript/JScript property (never put in written by ECMA nor
even by browser producers) is the high "durt tolerance". Other words
the interpreter is build on the presumption that the users will try to
code with the maximum violation of coding rules and culture: missing
parenthesis, simicolons, pending else's etc. etc. This tradition comes
from Netscape, because LiveScript from the very beginning was made as a
"folk language" targeted to people who may never ever program before.
If you want to find some property of JavaScript that realy differs it
from other languages then this is one.

Owerall IE is the most "durt tolerant" browser on the market. It will
try to understand any "pidgin script" where any other browser would
give up on the first line.

In case of HTMLElement.style.backgroundColor = "foobar" IE indeed
demostrates some unnecessary "code care".

The assignment backgroundColor = someColor is a request of value to the
build-in color table. So backgroundColor = "redd" is a request of a
value using non-existing key (redd). So programmatically it's equal to
backgroundColor = undefined. So yes, IE should(?) simply ignore it and
use default color instead.
BTW in case of document.body.style.backgroundColor = undefined it does
it (uses default color).

[color=blue]
> If I set background-color to "foobar", it doesn't work in neither
> browser!. Even more strange: changing "foobar" to "eggog" doesn't
> help!?[/color]

:-)

Irrelevant to the topic but maybe useful for the common programming:

The names "foo", "bar" and "foobar" are coming from Perl. Traditionally
they are used to denote some useless variables, functions and objects.
In the code stream it's like a comment: "this statement does nothing
useful, it's only for testing/demonstration purposes". The origin of
these names is lost by now, but we can guess that at least "foo" stays
from "foolish". (?)

"eggog" (originally "EGGOG") is coming from the first calculators with
build-in programming abilities. In case of a fatal math error prosessor
did the registers dump. This dump converted to ASCII was equal to
"EGGOG" string, this is what you saw on the display. From that time in
the programming sub-culture EGGOG means something fatally erroneus
("Change it, or EGGOG will get your program!"). It's getting obsolete
by now.

re: backgroundColor

VK wrote:[color=blue]
> The names "foo", "bar" and "foobar" are coming from Perl. Traditionally
> they are used to denote some useless variables, functions and objects.
> In the code stream it's like a comment: "this statement does nothing
> useful, it's only for testing/demonstration purposes". The origin of
> these names is lost by now, but we can guess that at least "foo" stays
> from "foolish". (?)[/color]

I've always understood that foobar derived from the common (at least in
America) acronymn FUBAR, which is inappropriate to expand in a public
forum.

The final four letters, though, indicate: Up Beyond All Recognition.
Guess what the F stands in for.

I may be mistaken there, but considering how terse one can get with the
language, and the incredible amount of magic it performs for you, I've
always felt the acronymn was particularly well-suited.


I'll leave it at that since this is off-topic here.

re: backgroundColor

> I've always understood that foobar derived from the common (at least in[color=blue]
> America) acronymn FUBAR, which is inappropriate to expand in a public
> forum.[/color]

You're right:
<http://whatis.techtarget.com/definition/0,,sid9_gci748437,00.html>
Thank you for the hint.

And "foobar" then must be a "softened" form brought by some
Perl-humorist into the common use. Still in the programming practice
"foobar" is gone so far from the orifinal F-meaning, that now I guess
we can consider it as an all new word.

re: backgroundColor

VK wrote:[color=blue][color=green]
>>I've always understood that foobar derived from the common (at least in
>>America) acronymn FUBAR, which is inappropriate to expand in a public
>>forum.[/color]
>
>
> You're right:
> <http://whatis.techtarget.com/definition/0,,sid9_gci748437,00.html>
> Thank you for the hint.
>
> And "foobar" then must be a "softened" form brought by some
> Perl-humorist into the common use. Still in the programming practice
> "foobar" is gone so far from the orifinal F-meaning, that now I guess
> we can consider it as an all new word.
>[/color]

I think you'll find the usage of 'foo' and 'bar' as common dummy names
pre-date Perl (which was 'born' circa 1987).

<URL:http://groups-beta.google.com/group/soc.net-people/msg/716e3446db058d2d>

The link below indicates that foo:

"Probably originally propagated through DECsystem manuals by Digital
Equipment Corporation (DEC) in 1960s and early 1970s; confirmed
sightings there go back to 1972"

<URL:http://www.faqs.org/rfcs/rfc3092.html>

Considerably before the development of Perl.



--
Rob

re: backgroundColor

RobG wrote:[color=blue]
> VK wrote:[color=green][color=darkred]
> >>I've always understood that foobar derived from the common (at least in
> >>America) acronymn FUBAR, which is inappropriate to expand in a public
> >>forum.[/color]
> >
> >
> > You're right:
> > <http://whatis.techtarget.com/definition/0,,sid9_gci748437,00.html>
> > Thank you for the hint.
> >
> > And "foobar" then must be a "softened" form brought by some
> > Perl-humorist into the common use. Still in the programming practice
> > "foobar" is gone so far from the orifinal F-meaning, that now I guess
> > we can consider it as an all new word.
> >[/color]
>
> I think you'll find the usage of 'foo' and 'bar' as common dummy names
> pre-date Perl (which was 'born' circa 1987).
>
> <URL:http://groups-beta.google.com/group/soc.net-people/msg/716e3446db058d2d>
>
> The link below indicates that foo:
>
> "Probably originally propagated through DECsystem manuals by Digital
> Equipment Corporation (DEC) in 1960s and early 1970s; confirmed
> sightings there go back to 1972"
>
> <URL:http://www.faqs.org/rfcs/rfc3092.html>
>
> Considerably before the development of Perl.
>
>
>
> --
> Rob[/color]

More and more interesting! Thank you.

P.S. And hell on backgroundColor! :-)

re: backgroundColor

VK wrote:[color=blue][color=green]
>>I've always understood that foobar derived from the common (at least in
>>America) acronymn FUBAR, which is inappropriate to expand in a public
>>forum.[/color]
>
>
> You're right:
> <http://whatis.techtarget.com/definition/0,,sid9_gci748437,00.html>
> Thank you for the hint.
>
> And "foobar" then must be a "softened" form brought by some
> Perl-humorist into the common use. Still in the programming practice
> "foobar" is gone so far from the orifinal F-meaning, that now I guess
> we can consider it as an all new word.[/color]

There was probably some influence from the use of the nonsense word
"foo" in the surreal comic strip "Smokey Stover". See
<URL:http://www.toonopedia.com/smokey.htm>.

--
John W. Kennedy
"Compact is becoming contract,
Man only earns and pays."
-- Charles Williams. "Bors to Elayne: On the King's Coins"

re: backgroundColor

"Richard Cornford" <Richard@litotes.demon.co.uk> writes:
[color=blue]
> The CSS specification requires that unknown/unrecognised properties and
> value be ignored. This is generally a good idea as it allows newer
> features to be added and not cause problems for older implementations.[/color]

The CSS specification is for CSS content, not setting via Javascript.
The relevant standard for that is the W3C DOM Level 2 Style
specification, in this case the setProperty method on the
CSSStyleDeclaration interface.
<URL:http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration>

According to specification, the setProperty method is expected to
throw a DOMException if the value to set "has a syntax error and is
unparsable". Whether that includes "somewhat parsable but
meaningless" is not elaborated, but I wouldn't fault a browser for
throwing an exception on any illegal value.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: backgroundColor

Lasse Reichstein Nielsen wrote:[color=blue]
> Richard Cornford writes:
>[color=green]
>> The CSS specification requires that unknown/unrecognised
>> properties and value be ignored. This is generally a good
>> idea as it allows newer features to be added and not cause
>> problems for older implementations.[/color]
>
> The CSS specification is for CSS content, not setting via
> Javascript. The relevant standard for that is the W3C DOM
> Level 2 Style specification, in this case the setProperty
> method on the CSSStyleDeclaration interface.
><URL:http://www.w3.org/TR/DOM-Level-2-Sty...CSSStyleDeclar[/color]
ation>[color=blue]
>
> According to specification, the setProperty method is
> expected to throw a DOMException if the value to set "has
> a syntax error and is unparsable". Whether that includes
> "somewhat parsable but meaningless" is not elaborated, but
> I wouldn't fault a browser for throwing an exception on
> any illegal value.[/color]

But wouldn't that be "has a syntax error and is unparsable" by CSS
standards? And an unknown/unrecognised value (so long as it is not a
syntax error; contains a colon or some such) can be parsed, just as it
would be in a style sheet.

Richard.