Finish implementing fixNesting(). Removed security-in-depth check for optimization reasons, since the info array will never cause such a condition.

git-svn-id: http://htmlpurifier.org/svnroot/html_purifier/trunk@58 48356398-32a2-884e-a903-53898d9a118a

docs/spec.txt

@@ -155,12 +155,18 @@ The way, I suppose, one would check for it, is whenever a node is removed,
 scroll to it's parent start, and re-evaluate it. Make sure you're able to do
 that with minimal code repetition.
 
+EDITOR'S NOTE: this behavior is not implemented by default, because the
+default configuration has a setup that ensures that cascading node removals
+will never happen. However, there will be warning signs in case someone tries
+to hack it further.
+
 The most complex case can probably be done by using some fancy regexp
 expressions and transformations. However, it doesn't seem right that, say,
 a stray <b> in a <table> can cause the entire table to be removed. Fixing it,
-however, may be too difficult.
+however, may be too difficult (or not, see below).
 
-This code was ripped from the PEAR class XML_DTD. It implements regexp checking.
+This code was excerpted from the PEAR class XML_DTD. It implements regexp
+checking.
 
 --
 
@@ -259,6 +265,11 @@ So... I say delete the node when PCDATA isn't allowed (or the regex is too
 complicated to determine where PCDATA could be inserted), and translate the node
 to text when PCDATA is allowed.
 
+--
+
+Note that generic child definitions are not usually desirable: we should
+implement custom handlers for each one that specify the stuff correctly.
+
 == STAGE 4 - check attributes ==
 
 While we're doing all this nesting hocus-pocus, attributes are also being