domDocument - глючит парсер

Данный код - какая-то лапша

css({toppos['top'])+'px',leftpos['left'])+'px',width.offsetWidth+'px',height.offsetHeight+'px',display:''})

Пусть и лапша, проблема в DOM парсере, он должен всю лапшу оставлять внутри <script> и </script>. Вот другой пример исковерканого кода:

Было:

Стало:

Если сделать обратную замену </script>\r\n</div>'); на </div>'); не составляет труда, то написать код который будет определять универсальным образом то место куда нужно вставить пропавший </script> - не реально.

А какой смысл запихивать в парсер заведомо невалидный код? Хотите проверить, как парсер исправляет ошибки? Так он и наисправляет, исходя непонятно из каких соображений.

Моя задача из заведомо правильного либо неправильного HTML документа (это я не знаю) сделать правильный, почищенный от мусора. Мусор чистится нормально, проблема возникает только при наличии </div> внутри JS кода.

Поставьте </nav> вместо </div> - то же самое будет. Проблемы не в div, а в <script>. ХЗ в чём там дело, но у domDocument всегда были проблемы со скриптами.

Он ищет любые закрывающие теги, находит его в теле строковой константы, далее понимает что раз тег закрывается значит это незакрытый <script>, закрывает его и ставит перевод строки, после чего крашится вся разметка. Отключить "исправление" таких "ошибок", по видимому, нельзя. Для меня это новость потому что не первый год работаю с DOMDocument, да, скармливал ему обычно отрывки документов, выводы из визуальных редакторов и прочие дела, но почти никогда всю страницу целиком, но даже если целиком (задача была извлечения текста статьи из HTML кода с определением тега внутри которого содержится контент) то таких приколов не было...

Не стал сильно разбираться, но в глаза бросилась проблема со скобками. Одна открывающая и три закрывающих.

Да это пример одного из сбойных кодов... на вход парсеру может подаваться все что угодно, главное чтобы это правильно обрабатывалось. Выше я привел другой пример абсолютно валидного кода, но который тоже валится. Сейчас буду пробовать альтернативные решения в других языках программирования, потому что это не дело.