any html(5) tag that renders whitespace at the end

[kutchbhi]

The situations:
I have text in a var, that I am assigning to the innerhtml of a 'p' tag . The text has whitespace at the end.

The problem:
The last whitespace isn't rendered, by p tags. IT is ignored.

Is there a tag other than the pre tag, that can render whitespace at the end ?

I know I can use   , but due to the nature of a processing function , I can't use nbsp. 'pre' tag doesn't seem to respect the css width property. SO the only way forward seems to be a mythical tag that would render all whitespaces (beginning,end).

Help ?

Thanks

try replacing spaces at the end with  

[Troy III]

The situations:
I have text in a var, that I am assigning to the innerhtml of a 'p' tag . The text has whitespace at the end.

The problem:
The last whitespace isn't rendered, by p tags. IT is ignored.

Is there a tag other than the pre tag, that can render whitespace at the end ?

I know I can use   , but due to the nature of a processing function , I can't use nbsp. 'pre' tag doesn't seem to respect the css width property. SO the only way forward seems to be a mythical tag that would render all whitespaces (beginning,end).

Help ?

Thanks

You have a text and you want to insert it into a P element[?], -good! But you don't want to innerHTML the damn text, -you want to innerText it, like here:

oElement.innerText=myVarText

there you go. A trailing white-space appears!
Have fun.

[Airshow]

Is .innerText cross-browser there days? FF was always the odd-man-out but maybe they fixed it at some point.

If you always want a space at the end, then (depending on exactly what effect you want and why you want it) you may be able to render it with CSS padding-right instead of text.

Airshow

[Troy III]

Is .innerText cross-browser there days? FF was always the odd-man-out but maybe they fixed it at some point.

If you always want a space at the end, then (depending on exactly what effect you want and why you want it) you may be able to render it with CSS padding-right instead of text.

Airshow

*
Yes, but that fully satisfies roughly 90% of your clients. Chrome understands it, Safari understands it, Opera understands it, all versions of IE understand it [these alone constitute more than 67% of the "pie" in total.
**
Using css on dynamically generated and parsed content defeats the purpose of dynamically generating it. [cause it] Demands planning since the beginning. Than what's the purpose of dynamically generating it?
***
Yet, like most of the times there are alternatives.
You can do something like:

oElement[oElement.innerText?"innerText":"textContent"]=myVarText

and it should fix it - all across.
My kind regards.

[Airshow]

Unfortunately not.

Consider what would happen with an initially empty paragraph in any browser that supports element.innerText but not element.innerContent . oElement.innerText would be falsy (empty string) and the statement would assign oElement["textContent"] = myVarText . Opera, FF, Chrome, Safari and IE9 would be fine but IE5.5, IE6, IE7 and IE8 would fail silently.

There are still enough IE5.5/6/7/8 users out there to worry about.

How about?:

oElement[oElement.hasOwnProperty('innerText')?"innerText":"textContent"] = myVarText;

Airshow

[Troy III]

Unfortunately not.

Consider what would happen with an initially empty paragraph in any browser that supports element.innerText but not element.innerContent . oElement.innerText would be falsy (empty string) and the statement would assign oElement["textContent"] = myVarText . Opera, FF, Chrome, Safari and IE9 would be fine but IE5.5, IE6, IE7 and IE8 would fail silently.

There are still enough IE5.5/6/7/8 users out there to worry about.

How about?:

oElement[oElement.hasOwnProperty('innerText')?"innerText":"textContent"] = myVarText;

Airshow

:)

-(You mean "textConent"!),
Yes I must admit that I wrote it [as a fast patch and go] on a wrong assumption that an elements predefined property values are all initially "null" as are those of event properties. But thankfully I was wrong!
Properties like innerText or textContent should have their initial values Empty but of a correct Data Type (as should other types of properties), in this case: of a String Type.

An Empty String [""} just like "null" represents the [empty] type of the given property value, a correct one -(to make e digression) that's why typeof null should return "object", [and it does return "object"], not "null" -because 'null' doesn't mean anything at all.

I'm not saying that having a complementary "typeOf" operator [with a capital O] which would return "null" for null, would harm anything, on contrary -I think it's a must have operator. Its acting would be analogous to == and === comparison syntax, - implicit vs explicit : dynamic vs static.

That would be a great advance since having an explicit typeOf vs the existing implicit one, would for instance make possible things like:

inpt = typeOf(x)
if( inpt == "undefined")
if( inpt == "NaN")
if( inpt == "null")
if( inpt == "false")
if( inpt == "0")
if( inpt == "true")
if( inpt == "1")
if( inpt == "Infinity")
if( inpt == "-Infinity")
if( inpt == "")
if( inpt == "[]")
if( inpt == "{}")
if( inpt == "Object")
if( inpt == "Array")
if( inpt == "Function")
if( inpt == "String") 
if( inpt == "RegExp")
if( inpt == "Date")
if( inpt == "Number") *

* real number between 1 and infinity since 0 is an empty number same as null is an empty object that is -no object. Same as 0 bares a notion of a number but contains none. I've included 1 also because it is somewhat special in meaning and will undergo a duck-Type conversion if not caught explicitly.

Now, let's say that my assumption was bad,... -but yours is worst! :) and let us see why[?].

My assumption [including the run-on code solution] is correct up until the specific case when the element we are appending to is completely empty. I recall that edit apps (almost) all, auto-complete like "<p>| </p>" with a space. [but that's an excuse, yet it's a better prevention than adding lines of code down the script]. But almost 99% of all occasions the innerText\textContent is used, it is used to append or to replace the existing data dynamically -not to populate it. -That leaves us with about 1% fail cases only; -on the other hand, the dominant ie versions as you've already mentioned support the alternative method supplied which halves once again that 1% possibility. Which as we've already mentioned, can be fully prevented by simply adding a single space character between the target tags.

Now, the "How about oElement[oElement.hasOwnProperty('innerText')?"innerText":"textContent"] = myVarText; ".
The oElement.hasOwnPrperty should and will return false on all properties except those special custom properties assigned by the coder. No individual HTML element type has its own properties. They all inherit from constructor. This way even if the browser supports innerText by design your expression will suppress it.

oElement.hasOwnProperty('innerText') ; // false
oElement.hasOwnProperty('textContent'); // false

delete oElement.innerText // true

That's because we are deleting an nonexistent custom property-name presumed as innerText.
But it stays intact: i.e: oElement.innerText // "" , -not undefined; Because it exists higher up in the prototype chain.

So to finally correct this and make a finished rock-solid method, we can:

[B]oElement["innerText" in oElement?"innerText":"textContent"]="any text with a trailing space "[/B]

and do it with confidence.

[Airshow]

Correct Troy, I meant .textContent .

And yep, agreed prop in obj is best. Good solution.

It's academic but out of interest, browsers differ their implementation of these properties.

• Opera : oElement.hasOwnProperty('innerText') gives true
• IE9 : oElement.hasOwnProperty('innerText') gives false

Both support .innerText , so it's a question of own vs. inherited - therefore unreliable to test .hasOwnProperty() .

Airshow

[Troy III]

Correct Troy, I meant .textContent .

And yep, agreed prop in obj is best. Good solution.

It's academic but out of interest, browsers differ their implementation of these properties.

• Opera : oElement.hasOwnProperty('innerText') gives true
• IE9 : oElement.hasOwnProperty('innerText') gives false

Both support .innerText , so it's a question of own vs. inherited - therefore unreliable to test .hasOwnProperty() .

Airshow

Well, that's odd. I never knew that Opera DOM elements don't inherit! Or do they?...
There's something odd going on there, and it needs to be tested before drawing any conclusion.

Probing something like:

var p = document.createElement("p")
p.innerText // > "" // correct!
delete p.innerText // > true
p.innerText // > ""  //intact!
/*should yield "undefined" if property was earned */

But it doesn't. Meaning that native properties of elements are indeed inherited from their corresponding prototypes, which on the other hand says that element hasOwnPrperty in Opera is browsing its constructor properties instead of its own.
The: delete p.innerText // which doesn't destroy the Type of its innerText property from "" to undefined, assures us that the property is indeed inherited. Which makes it clear that this behavior is Operas bug of its hasOwnPrperty implementation and should be reported.

[Airshow]

... Meaning that native properties of elements are indeed inherited from their corresponding prototypes, ...

Hi Troy, I wonder is that the only possible conclusion.

You may well be right but could it not alternatively be that this property is simply undeletable, ie. it doesn't not respond to delete , at least not in the normal way? If I'm right, the symptoms in your tests above would be the same(?).

I can't immediately think of a test that would definitively tell the difference between a hasOwnProperty() bug and "undeletability". Maybe you can, or maybe it's already there but I can't see it.

Airshow

[Airshow]

On the other hand, reading here, I see that domElement.hasOwnProperty() is known to behave differently in the various broswers.

So yes, a hasOwnProperty() bug/difference is the more likely explanation over my alternative "undeletability" theory.

Airshow

[Troy III]

Your assumption is right. It is there...
The line:

delete p.innerText // >> true.

Undeletable property flag would also disable its write ability and as a consequence we would get a read-only innerText property.
The innerText (as other initial element properties) is inherited from the prototype: not owned by the element itself. (That's why the line 4 persistently returns "" which is found up the prototype chain instead of expected 'undefined') As soon as we assign something tho the innertext property of the element it gets created and overshadows the initial value existing higher on its prototype. That's why as soon as we delete it (line 3) the line 4 value will shine through again, which is by the way one of the most powerful principles in Live Script.

Aside all that, the "hasOwnProperty" method was introduced and (is by definition) designed and defined in a way that it would allow only owned properties of the current object to 'shine through' or be exposed to the code. Any behavior other than that, is a bug; a wrong implementation, or implementation error.
If needs to be said: it defeats the purpose and the reason of its existence.