Дзен Кодинг не учитывает необязятельность закрывающих тэгов.

[GoogleCodeExporter]

Простой код вроде {{{
<div>
    <p>|
</div>
}}}
приводит к выделению от <p> до </div>. Как 
известно, закрывающий тэг </p> необязателен. 
(А также все табличные кроме table и caption, </dt>, 
</dd>, </li>, </head>, </body>, <tbody>, </html> и т.п.)

Original issue reported on code.google.com by GreLIm...@gmail.com on 26 Dec 2010 at 8:37

[GoogleCodeExporter]

С этим проблемы на уровне парсера. Чтобы 
правильно обработать такие ситуации нужно 
полностью распарсить документ, потому что 
не всегда понятно, есть ли вложенность у 
этого тэга и какой диалект языка 
используется (html, xhtml, xml). При этом 
потеряется возможность основная фича 
текущего парсера: читать xhtml из любого 
места, даже из javascript строки

Original comment by serge....@gmail.com on 30 Jan 2011 at 2:28

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

По моему разумению, можно проверять при 
поиске закрывающего тэга, что попавшийся 
открывающий тэг не может быть в текущем. В 
абзаце <p> не может быть блочных элементов, 
элементы списков и таблиц ограничены 
своими структурными элементами.
Например, следующий <li> или </ol>/</ul> закрывает 
текущий, аналогично, но несколько сложнее 
с таблицами: <td> может быть закрыт следующим 
<td> или элементом более высокого уровня, 
таким как <tr>, <tbody>. Но не <table>! Только 
закрывающим </table>.
Они ограничены структурой: вложенность 
может быть только тогда, когда есть 
соответствующий основной элемент как <ul> 
или <table>.
Таким образом полноценный парсер 
не представляется обязательным. Он нужен 
для корректной обработки ошибок, чего Zen 
Coding не обязан делать.

Original comment by GreLIm...@gmail.com on 30 Jan 2011 at 3:29

[GoogleCodeExporter]

Дело не в этом. Основная проблема — 
определение правильных границ при поиске. 
Сейчас просто формируется стэк 
закрытых/незакрытых тэгов, так только 
находим закрывающий тэг и пустой стэк — 
останавливаемся. 

Например, сейчас основная проблема: при 
обратном поиске (то есть поиск назад, от 
текущей позиции каретки) найдя незакрытый 
тэг P я не могу с уверенностью сказать, что 
это именно тот открывающий тэг, который 
нужен пользователю, или же я должен 
подняться выше и проматчить DIV или другой 
обрамляющий элемент. 

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

Original comment by serge....@gmail.com on 31 Jan 2011 at 10:24