Do:
var isTrueSet = (myValue === 'true');
using the identity operator (===
), which doesn't make any implicit type conversions when the compared variables have different types.
Don't:
You should probably be cautious about using these two methods for your specific needs:
var myBool = Boolean("false"); // == true
var myBool = !!"false"; // == true
Any string which isn't the empty string will evaluate to true
by using them. Although they're the cleanest methods I can think of concerning to boolean conversion, I think they're not what you're looking for.
Warning! This answer is too old and doesn't work on modern browsers.
I'm not the poster of this answer, but at the time of writing this, this is the most voted answer by far in both positive and negative votes (+1035 -17), and it's still marked as accepted answer (probably because the original poster of the question is the one who wrote this answer).
As already noted many times in the comments, this answer does not work on most browsers anymore (and seems to be failing to do that since 2013).
After over an hour of tweaking, testing, and trying different styles of markup, I think I may have a decent solution. The requirements for this particular project were:
- Inputs must be on their own line.
- Checkbox inputs need to align vertically with the label text similarly (if not identically) across all browsers.
- If the label text wraps, it needs to be indented (so no wrapping down underneath the checkbox).
Before I get into any explanation, I'll just give you the code:
label {
display: block;
padding-left: 15px;
text-indent: -15px;
}
input {
width: 13px;
height: 13px;
padding: 0;
margin:0;
vertical-align: bottom;
position: relative;
top: -1px;
*overflow: hidden;
}
<form>
<div>
<label><input type="checkbox" /> Label text</label>
</div>
</form>
Here is the working example in JSFiddle.
This code assumes that you're using a reset like Eric Meyer's that doesn't override form input margins and padding (hence putting margin and padding resets in the input CSS). Obviously in a live environment you'll probably be nesting/overriding stuff to support other input elements, but I wanted to keep things simple.
Things to note:
- The
*overflow
declaration is an inline IE hack (the star-property hack). Both IE 6 and 7 will notice it, but Safari and Firefox will properly ignore it. I think it might be valid CSS, but you're still better off with conditional comments; just used it for simplicity.
- As best I can tell, the only
vertical-align
statement that was consistent across browsers was vertical-align: bottom
. Setting this and then relatively positioning upwards behaved almost identically in Safari, Firefox and IE with only a pixel or two of discrepancy.
- The major problem in working with alignment is that IE sticks a bunch of mysterious space around input elements. It isn't padding or margin, and it's damned persistent. Setting a width and height on the checkbox and then
overflow: hidden
for some reason cuts off the extra space and allows IE's positioning to act very similarly to Safari and Firefox.
- Depending on your text sizing, you'll no doubt need to adjust the relative positioning, width, height, and so forth to get things looking right.
Hope this helps someone else! I haven't tried this specific technique on any projects other than the one I was working on this morning, so definitely pipe up if you find something that works more consistently.
Warning! This answer is too old and doesn't work on modern browsers.
Best Answer
Update: I wrote a blog post detailing all the differences much better.
Firefox uses W3C standard
Node::textContent
, but its behavior differs "slightly" from that of MSHTML's proprietaryinnerText
(copied by Opera as well, some time ago, among dozens of other MSHTML features).First of all,
textContent
whitespace representation is different frominnerText
one. Second, and more importantly,textContent
includes all of SCRIPT tag contents, whereas innerText doesn't.Just to make things more entertaining, Opera - besides implementing standard
textContent
- decided to also add MSHTML'sinnerText
but changed it to act astextContent
- i.e. including SCRIPT contents (in fact,textContent
andinnerText
in Opera seem to produce identical results, probably being just aliased to each other).textContent
is part ofNode
interface, whereasinnerText
is part ofHTMLElement
. This, for example, means that you can "retrieve"textContent
but notinnerText
from text nodes:Finally, Safari 2.x also has buggy
innerText
implementation. In Safari,innerText
functions properly only if an element is neither hidden (viastyle.display == "none"
) nor orphaned from the document. Otherwise,innerText
results in an empty string.I was playing with
textContent
abstraction (to work around these deficiencies), but it turned out to be rather complex.You best bet is to first define your exact requirements and follow from there. It is often possible to simply strip tags off of
innerHTML
of an element, rather than deal with all of the possibletextContent
/innerText
deviations.Another possibility, of course, is to walk the DOM tree and collect text nodes recursively.