Js-beautify: "неформатированная" парадигма нарушена, "неформатированный" и "встроенный" - не одно и то же

Ваше предложение о том, как это должно работать, звучит разумно. Пожалуйста, укажите, какие элементы должны быть встроенными, а какие - неформатированными. Затем реализуйте и отправьте запрос на перенос.

Я не уверен, что вы понимаете, о чем я говорю. Все элементы должны быть отформатированы! Просто некоторые из них встроены, а некоторые являются блочными элементами. Так было с XML / HTML / CSS уже пару десятилетий.

Если это блочный элемент, он визуально создает новый блок. Эти вещи при форматировании исходного кода HTML почти всегда имеют перед собой новую строку (как в исходном коде, так и при рендеринге). Перед встроенным элементом нет новой строки (как в исходном коде, так и при отображении). Но это не значит, что его _contents_ не следует форматировать. (Это означает, что в его содержимое не следует добавлять новые строки, если только вы не переносите строки.)

Так что это не твик. Это признание того, что вся парадигма, которую js-beautify использует для форматирования, нарушена. (Я не имею в виду - я просто объективен и пытаюсь помочь вам, объясняя.) Вам нужно различать три разные вещи:

• "форматирован" - этот элемент отформатирован? (По умолчанию все элементы должны быть отформатированы, если кто-то не отключит его.)
• «блок / отображение» - это блок или элемент отображения? Если это блочный элемент, он должен иметь новую строку _prepended_ перед начальным тегом, и он должен иметь отступ до текущего уровня отступа. В противном случае перед ним не должно быть новой строки.
• "контейнер" - эта штука обычно используется только для содержания других блочных элементов? Если это так, то новая строка должна быть сгенерирована _после_ начального тега, после конечного тега, а содержимое должно иметь отступ на новом уровне отступа. Это самый спорный вариант, то есть он будет сильно варьироваться в зависимости от вкусов пользователей. Один очевидный кандидат - <ul> ; его содержимое (например, <li> ) должно иметь отступ. Некоторые люди захотят добавить <p> в этот список, чтобы теги <p> были на отдельных строках. Другие (например, я) не захотят, чтобы они помещались в отдельные строки.

Я предлагаю вам ознакомиться с блочной моделью CSS и понять, как работает блочная и встроенная. А затем перепишите логику форматирования HTML js-beautify с учетом блочной модели CSS (потому что исходный код должен отражать, как в конечном итоге будет выполняться рендеринг).

По умолчанию ничего не должно быть «неформатированным». Все должно быть отформатировано - просто отформатировано соответствующим образом. «unformatted» должен быть последней инстанцией для пользователя, чтобы сказать: «эй, мне не нравится то, что делает js-beautify, поэтому просто не трогайте этот элемент и позвольте мне разобраться с ним.

PS Я уже дал вам начало в # 840, указывая, что составляет встроенный элемент в HTML5. Однако у меня сейчас нет времени переписывать весь ваш механизм форматирования. Если у меня будет это время, было бы эффективнее написать свое собственное. А пока я пытаюсь помочь вам, чтобы вы смогли заставить свою работу работать, что было бы лучше для нас обоих. Удачи, и дайте мне знать, какую дополнительную информацию я могу предоставить.

Я полностью понимаю, что вы сказали изначально. Вы считаете, что в html beautifier есть ошибка. Вы хотели бы описать это как «нарушена вся парадигма, которую js-beautify использует для форматирования [html]». Я не проектировал и не внедрял модуль html beautifier, и за время моего пребывания в качестве сопровождающего этого проекта он увидел наименьшие улучшения. Он определенно требует внимания и значительной доработки, как и CSS-улучшитель в этом отношении.

Тем не менее, html beautifier делает некоторые вещи достаточно приемлемым способом, несмотря на свои недостатки. И я сомневаюсь в вашей оценке того, что обработка # 840, в частности, потребует «переписывания» или изменения «парадигмы». Это улучшение, как и любое другое. Вероятно, есть несколько способов реализовать это, от уродливого взлома до полной переделки и переписывания.

Каким бы ни был объем, я думаю, что описанные вами изменения в конечном итоге стоит внести, но у меня уже есть значительный список конкретных, хорошо описанных, очень востребованных исправлений ошибок и функций, которые в целом имеют более высокий приоритет для проекта. Я должен потратить то немного времени, которое у меня есть на этот проект, на эти предметы. Если вы действительно считаете, что это стоит исправить сейчас, вам придется потратить на это свое время. Я приветствую пул-реквесты.

Вы считаете, что в html beautifier есть ошибка.

Нет, я говорю, что нет способа указать js-beautify не помещать разрыв строки _ перед_ элементом, не сообщая при этом js-beautify не форматировать что-либо внутри элемента. Это правда или нет?

Вы хотели бы описать это как «нарушена вся парадигма, которую js-beautify использует для форматирования [html]».

Если js-beautify не знает разницы между «вещами, перед которыми не должны быть добавлены разрывы строк» ​​и «вещами, которые я должен вообще игнорировать», то да, его парадигма неадекватна даже для простого HTML. В конце концов, мне не нужен разрыв строки перед <dfn> (потому что это встроенный элемент), но если <dfn> содержит <img> , я не хочу js-beautify, чтобы отказаться от форматирования тега <img> . (Это надуманный пример; он применим к любому встроенному изображению.)

Так ты мне скажи. Может ли js-beautify отформатировать <img> внутри <dfn> не помещая перевод строки перед <dfn> ?

Суть того, что я говорю, заключается в том, что «не форматировать содержимое этого элемента» отличается от «не помещать новую строку перед этим элементом». Итак, позвольте мне спросить вас еще раз. Понимает ли js-beautify различие между этими двумя вещами или объединяет эти понятия? Если он не понимает разницы, его фундаментальная модель нарушается.

Но конечно, иногда можно обойти фундаментальные недостатки. Поэтому я возвращаюсь и снова спрашиваю вас: как бы мне обойти этот недостаток? Как мне сказать js-beautify не помещать перевод строки перед <code> а форматировать элемент <img> внутри <code> ?

@garretwilson Это доступно в 1.8.0-rc2 .