setting node.nodeValue+='&nbsp';

[madtom1999]

I'm trying to put a non-breaking space ( or any other entity for that
matter) into a node
eg:
node.nodeValue+='&nbsp';
however the actual code is written in the html -ie it displays as

&nbsp;< and not > <

any ideas?

[madtom1999]

Ok-gotit- you have to do String.fromCharCode( val);
so for &nbsp;
node.nodeValue+=String.fromCharCode(160);

codes from:
http://www.ascii.cl/htmlcodes.htm

[VK]

ma********@yahoo.com wrote:

I'm trying to put a non-breaking space ( or any other entity for that
matter) into a node
eg:
node.nodeValue+='&nbsp';

ECMA-262, Book of Source:
<http://developer.mozilla.org/js/specs/ecma-262#a-6>

Therefore:
'NO-BREAK SPACE' Unicode character is U+00A0 so in JavaScript must be
represented as \u00A0

node.nodeValue+= '\u00A0';

More entities can be found at
<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>
Use UFFFF codes in the rightmost column only in the form \uFFFF. Also
note that not all named entities are equally supported across browsers,
so do an extra check.

[Michael Winter]

On 22/12/2005 11:28, VK wrote:

ma********@yahoo.com wrote:

I'm trying to put a non-breaking space ( or any other entity for that
matter) into a node
eg:
node.nodeValue+='&nbsp';

^
I assume the missing semicolon is a typo?

Entity references are a feature in HTML. As the content model for SCRIPT
elements is CDATA, the contents will be passed through unaltered.
However, in intrinsic event attributes, entity references will be
transformed.

As you've already been told, find the Unicode code point value for the
entity in question, then use a Unicode escape sequence (\uXXXX).

[snip]
More entities can be found at
<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>
As I get more or less any empty page here, perhaps a better reference is
in order?

<http://www.w3.org/TR/html4/sgml/entities.html>

[snip]
Also note that not all named entities are equally supported across
browsers, so do an extra check.

As we're not using named entity references, I fail to see the point. As
it happens, numeric entity references (again, not strictly on-topic, but
relevant to your remark) are very well supported and will often work
where character entity reference will not.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[VK]

Michael Winter wrote:

As we're not using named entity references, I fail to see the point.

Sorry, I had to be more specific:

There are over 64 000 char entities just in Unicode16 and each of them
can be represented in JavaScript as \uFFFF. But naturally not all of
them can be displayed in the browser w/o installing an appropriate
font, say Traditional Chinese.

Usually HTML named characted entities like &nbsp; or &times; etc. are
able to be displayed in the default environment. So it's like a
guideline: if a character has HTML named entity then you may hope it
will be displayed properly (instead of unfamous empty square) using
\uFFFF

But still there are discrepancies you need to check against. For
example named entity &hearts; (\u2665) is OK by default for both IE and
FF.
At the same time named entity &image; (\u2111) is OK for FF but fails
on IE. The latter is a real shame because it's a very nicely stylized
letter J (I actually, but looks like J) just asking for JavaScript
related logos.

Therefore the only link having practical value is
<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>

It is a shame that it's not displayed in Firefox - there is nothing
browser specific in it, just regular Microsoft nastiness. If you want I
can strip the table down for you.

[Thomas 'PointedEars' Lahn]

VK wrote:

Michael Winter wrote:

As we're not using named entity references, I fail to see the point.
Sorry, I had to be more specific:

There are over 64 000 char entities just in Unicode16

There is no Unicode16.
and each of them can be represented in JavaScript as \uFFFF.
In JavaScript since version 1.3, within String or RegExp literals only.
Therefore the only link having practical value is
<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>

No, it is by far not the only one.
It is a shame that it's not displayed in Firefox -
No, it is not.
there is nothing browser specific in it,
There is, and that browser-specific behavior is non-standard.
just regular Microsoft nastiness.
It is completely invalid markup.

<URL:http://validator.w3.org/check?uri=http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp&ss=1;verbose=1>
If you want I can strip the table down for you.

No, thanks.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

There is no Unicode16.
<http://www.google.com/search?hl=en&lr=&q=Unicode16>

Convenience shortcut (like "<!-- --> comment tag")
In JavaScript since version 1.3, within String or RegExp literals only.
By ECMA 3rd edition - other is irrelevant.
<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>
No, it is by far not the only one.
There are plenty of such. But while making a cross-compatible subset
one starts from the biggest set and narrows it down.

It is a shame that it's not displayed in Firefox -

No, it is not.

Are you talking with me or with yourselve?
<my quote>
* is OK for FF but fails on IE*. The latter is a real shame because
it's a very nicely stylized letter J (I actually, but looks like J)
just asking for JavaScript related logos.
</my quote>
There is, and that browser-specific behavior is non-standard.
named entities and \uFFFF per se are not browser specific. Supported
sets are.
It is completely invalid markup.

Which could be still displayed rather than being hidden from non-IE's.
You browser has to parse much more non-standard pages while browsing
the Web.

If you want I can strip the table down for you.

No, thanks.

Proposal was not to you but as you wish.

Summary: did anyone really need this absolutely irrelevant post? And
btw what about HTML comments?

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

There is no Unicode16.
<http://www.google.com/search?hl=en&lr=&q=Unicode16>

Convenience shortcut (like "<!-- --> comment tag")

There is no "Unicode16", there is (the) Unicode (Standard) (currently
version 4.0) and character set, and the Unicode Transformation Format
UTF-16. That there are many more clueless people next to you out there
and that there may be a data type called `Unicode16' in some programming
languages, does not change that.

<http://www.unicode.org/>

In JavaScript since version 1.3, within String or RegExp literals only.

By ECMA 3rd edition - other is irrelevant.

Nonsense.

,-[news:11**********************@g44g2000cwa.googlegr oups.com]
|
| Therefore the only link having practical value is

<http://msdn.microsoft.com/workshop/author/dhtml/reference/charsets/charset2.asp>

No, it is by far not the only one.

There are plenty of such. But while making a cross-compatible subset
one starts from the biggest set and narrows it down.

You are winding around your nonsensical statement.

> It is a shame that it's not displayed in Firefox -

No, it is not.

Are you talking with me or with yourselve?

I am referring to your nonsensical statement.
<my quote>
* is OK for FF but fails on IE*. The latter is a real shame because
it's a very nicely stylized letter J (I actually, but looks like J)
just asking for JavaScript related logos.
</my quote>

I referred to the nonsense you stated now, here, in this thread.

There is, and that browser-specific behavior is non-standard.

named entities and \uFFFF per se are not browser specific. Supported
sets are.

The browser-specific non-standard behavior IE displays is to assume XHTML
without DOCTYPE declaration even if it is served as text/html just because
of the presence of an undeclared attribute of the `html' element
(xmlns:tool), to regard <![CDATA[ ... ]]> in HTML content a valid markup
declaration, and even if the former did not apply, to render content
declared as CDATA in XHTML as if it was PCDATA. And probably I forgot
some more.

It is completely invalid markup.

Which could be still displayed rather than being hidden from non-IE's.

1. No parser is obliged to render invalid markup.

2. No parser is obliged to render markup declarations; in fact, any
HTML-based parser that does so, is broken.

3. Firefox's HTML-based parser rightfully refuses to continue to parse
and to render the invalid markup declaration.
PointedEars

[VK]

OK, break! You won it, baby! :-)

[Jambalaya]

VK wrote:

OK, break! You won it, baby! :-)

Please quote to what you are replying.
<url:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>

Ha ha! Just kidding.

J

[Randy Webb]

VK said the following on 12/22/2005 11:41 AM:

<snip>

Summary: did anyone really need this absolutely irrelevant post? And
btw what about HTML comments?

Welcome to PointedHead. When he has nothing useful to say, he rants and
raves about irrelevant things.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jonas Raoni]

Randy Webb escreveu:

VK said the following on 12/22/2005 11:41 AM:

Summary: did anyone really need this absolutely irrelevant post? And
btw what about HTML comments? Welcome to PointedHead.

I was going to call him Spock, but I see he already got a nickname =/

When he has nothing useful to say, he rants and
raves about irrelevant things.

I used to be a troll, but this guy has really impressive skills... He
made me waste a lot of time today.
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Randy Webb]

Jonas Raoni said the following on 12/22/2005 7:13 PM:

Randy Webb escreveu:

VK said the following on 12/22/2005 11:41 AM:

Summary: did anyone really need this absolutely irrelevant post? And
btw what about HTML comments?

Welcome to PointedHead.

I was going to call him Spock, but I see he already got a nickname =/

They would both fit.

When he has nothing useful to say, he rants and
raves about irrelevant things.

I used to be a troll, but this guy has really impressive skills... He
made me waste a lot of time today.

He is very adept at trolling. The sad irony is that he actually does
have pretty good research skills when it comes to looking up, quoting,
and arguing the Specs. But I believe that most of his Specs posts are
copy/paste from elsewhere. You don't see a lot of real-world stuff from
him - mostly Theory.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jonas Raoni]

Randy Webb escreveu:

He is very adept at trolling. The sad irony is that he actually does
have pretty good research skills when it comes to looking up, quoting,
and arguing the Specs.
Definitely true, Spock should be a researcher ;]
But I believe that most of his Specs posts are
copy/paste from elsewhere. You don't see a lot of real-world stuff from
him - mostly Theory.

I'm new here, but it seems that you're right, until now I just saw
links from him... I googled him and took a look on his codes
[http://www.pointedears.de/scripts] and didn't found anything
interesting...

But he's a cool member :]
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[VK]

Jonas Raoni wrote:

Randy Webb escreveu:

He is very adept at trolling. The sad irony is that he actually does
have pretty good research skills when it comes to looking up, quoting,
and arguing the Specs.

Definitely true, Spock should be a researcher ;]

Irrelevant to any personality:

That is the very nature of W3C documentation (and the whole w3.org
site) that makes it a perfect source for endless quoting and arguing -
if one wants to. Three key components are:

1. Produce a paper on each step, but eventually follow the real world
winner, but do not remove or mark out anyhow any of previous papers,
would it be a preliminary draft, short note or a Christmas card to your
wife.

2. Physical unability of many W3C members to express themselve in
written form.

3. Dead stuberness in *little* issues where the risk to be publically
sent to the hell is not so high.

Therefore a question "what is the PI value up to 32 signs?" can be
answered quickly and clearly - but many of W3C standards can followed
in an endless discussion: because w3.org will provide enough of quotes
to prove that A is B as well as A is not B.
I did a small demonstration of that at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/01dd76b30c37d44c/1b4291ee71821173#1b4291ee71821173>

A sample for the point 3) :-
textarea *has* wrap property and always had since Netscape 2 and always
will have.
Moreover each wrap property has two sets of values:
original "physical", "logical" and "off" from Netscape
additional "hard", "soft" and "off" from Microsoft

This is a common knowledge fact and there are no browsers which would
not support at least the first set.
But wrap property *doesn't exists* by W3C, never existed and never will
exist. I don't know why did they pick on it, but they did. Extra
styling which one would suggest has nothing to do with the issue as it
is not styling issue - it's a flag to how to tread line breaks while
preparing the content for submission. So it is a required and used
*form-related* attribute.

As a result even Firefox has to violate W3C docs in this part to not
looking idiotic.