Небольшой препроцессор HTML

Было принято решение написать препроцессор HTML, который просто убирал бы закрывающие теги и использовал питоний синтаксис определения позиции блока.

К сравнению:

<!DOCTYPE html>
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>HTML Document</title>
   </head>
   <body>
      <p>
         <b>
            Этот текст будет полужирным, 
            <i>а этот — ещё и курсивным</i>
         </b>
      </p>
   </body>
</html>

Может быть переписан как:

<!DOCTYPE html>
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>HTML Document
   <body>
      <p>
         <b>
            Этот текст будет полужирным, 
            <i>а этот — ещё и курсивным

Второй, на мой взгляд, короче, быстрее набирается, легче читается и правится.

Код транслятора здесь, инструкция прилагается.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 46

    +3
    Ага, ищи потом, где у тебя какой тег закончился, если он за границы экрана ушёл или отступов штук 10 будет.
      +15
      Вы переизобрели HAML или Jade, только похуже.
        –4
        нет, я обрезал HTML не добавляя своих смайликов
          +2
          А цель была какая? Снизить избыточность HTML, чтобы лишние символы не вводить? Вы пошли в ожидаемом направлении, но остановились на половине пути: например, символы < и > тоже можно было бы исключить, как это сделали Jade и HAML. В общем, до их уровня емкости кода не дотянули, а вот поддержка редакторов уже потеряна. Поэтому и хуже.
            0
            Это дело вкуса.
            Печатаю в sublime, удобно.
        +2

        Вопрос, зачем?

          +1
          Присоединяюсь, следуя логике можно еще написать процессор который удаляет текст, оставляя лишь тэги, или удаляет атрибуты…
            +1
            Ага в любой современной IDE с использованием автокомплита и, допустим Emmet, никаких преимуществ в скорости набора любого шаблонизатора перед чистым HTML нет, имхо.
            У шаблонизаторов другие цели и соответственно другие преимущества.
            0
            Есть несколько замечаний.

            Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.

            Зависимость от Codeblocks — это неудобно. Можно использовать CMake в качестве системы сборки. Он более распространен и его проще поставить. CMake сможет сгенерировать проектные файлы и для CodeBlocks, и для VS, а также Makefile для многих ОС и окружений.

            Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
              –5
              Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.

              Не первый раз такое читаю, но логичного объяснения никто не даёт, разве что github для кода. При этом хочу отметить что весь код собран в своей папке, бинарники в своей, и если кому-то мешают бинарники, то их легко удалить.

              Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.

              Опять же, всё легко переписывается, я никому палок в колёса не вставляю.
                +6
                > Не первый раз такое читаю, но логичного объяснения никто не даёт,

                Во-первых, это почти всегда бессмысленно. Если кто-то скачивает исходный код вашего проекта, то он это делает для того, чтобы скомпилировать его из этих исходных кодов. В этом случае артефакты сборки ему совершенно не нужны. Если кому-то нужен exe-файл, то ему при этом не нужны исходники. Для выкладывания готовых файлов на github есть Releases. Кроме того, часто для работы exe-файлы нужны всякие dll-файлы зависимостей (правда, некоторые могут и эти dll в репозиторий добавить). Ну, а объектные файлы почти наверняка никому не пригодятся.

                К тому же сборочные файлы могут зависеть от ОС и окружения и могут даже вызвать проблемы со сборкой (файл не пересобирается, потому что он уже есть, но его не получается использовать, т.к. его формат несовместим с текущим окружением).

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

                В-третьих, бинарные файлы будут изменяться с каждым изменением кода и будут засорять историю изменений, ради которой система контроля версий и затевается. Хочется, глядя на коммит, быстро увидеть, какие файлы в нем изменились, и постоянные бессмысленные изменения бинарных файлов в каждом коммите будут очень мешать.
                  +1
                  Ну вот, достойное объяснение, полностью согласен, удалил бинари.
                    +4

                    В четвёртых, при мёржах веток будут постоянно возникать конфликты.


                    В-пятых, если исходник был изменён без пересборки, то будет несоответствие версий.

                +4
                >Было принято решение написать препроцессор HTML
                А самое интересное вы в статье так и не упомянули, что же все таки привело к принятию такого решения.
                  –3
                  Внимательно читайте статью:
                  Второй, на мой взгляд, короче, быстрее набирается, легче читается и правится.
                    0
                    Т.е. у вас была проблема с быстрым набором, прочтением и исправлением html и вы решили ее созданием своего «minHTML», вместо, например использования макросов в IDE? миленько :)
                  0

                  Okay, вот вам HTML:


                  <b>Bold <i>Bold italic </b>Italic</i>

                  Что там на выходе будет?

                  • НЛО прилетело и опубликовало эту надпись здесь
                      –4

                      Что значит garbage? Это корректный HTML (хотя, конечно, некорректный XML). И он прекрасно показывается всеми браузерами.

                        +3
                        >Это корректный HTML
                        Справедливости ради, то что он прекрасно показывается (а всеми ли? тысячи же их) браузерами, не значит что он корректный. Собственно если, хотите говорить о корректности, то начните уж с доктайпа и с того что он w3c хотябы без ошибок проходит.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Есть валидатор: https://validator.w3.org/#validate_by_input+with_options
                            В общем случае суем туда весь документ и смотрим на количество Errors, если они есть, то хтмл обычно считается не валидным, там же будет описание, довольно подробно, почему.
                            warnings тоже указывают на некоторые проблемы, но не все считают это признаком невалидности, мне тоже кажется, что там есть спорные.

                            Однако тут есть нюанс, валидация по сути основывается на doctype и рассматривать валидность документа можно только в контексте его.

                            Кстати тут есть такой прикольный момент, в целом можно создать свой doctype обозначить там свои правила и это тоже будет некий «валидный хтмл». И кстати, вполне возможно, что через это можно создать некий minHTML, без всяких левых препроцессоров.
                            0

                            Ок, про корректность я, конечно, погорячился. Но как тогда назвать HTML, который должны показывать (одинаково при этом) все нормальные браузеры? Помнится, когда-то (достаточно давно) я тоже писал свой микро-браузер, и с парсингом подобных конструкций тоже намаялся (равно как и с возможным отсутствием некоторых закрывающих тегов). Корректно это? Нет. Так пишут только *удаки? Да. Надо ли это показывать? Увы, да.

                              0
                              >Но как тогда назвать HTML, который должны показывать
                              >(одинаково при этом) все нормальные браузеры?
                              Так логично же, что валидным или корректным хтмл например.
                              Штука в том, что то что написали вы они показывать корректно не должны, хоть возможно и показывают, это собственно вообще не хтмл, это строчка неких символов.
                          –1
                          Вот вам тогда такой HTML:
                          <b>Bold
                            <i>Bold
                               italic</i>
                                 Ita</b>
                          lic
                          


                          Где после кастрации препроцессором будет кончаться курсив, а где болд?
                            0
                            Вы не поняли, он транслирует в HTML.
                              +1
                              Не спорю, что не понял.
                              Тем не менее, что ваше творение сделает с вышеприведенным фрагментом? Если просто обрежет закрывающие теги, то оригинальное форматирование поломается.
                        +2

                        Так в хтмл и так можно не писать закрывающийся тег:


                        <p>Hello,
                        <p>world!

                        Как только замечен новый открывающийся тег — предыдущий закрывается.

                          +1
                          >Так в хтмл и так можно не писать закрывающийся тег:
                          Далеко не у всех тегов закрывающий необязателен.
                          0
                          *промахнулся deleted
                            +4
                            Это разве статья?
                              +1
                              Jade вам в помощь.
                              https://habrahabr.ru/post/278109/
                                0
                                Не нашел в коде правил стандартного автозакрытия тегов.
                                  0
                                  Самый верх файла minHTML.c
                                  Там перечислены все одиночные теги.
                                  0
                                  Мнение валидатора уже не важно?

                                    +1
                                    Валидатор обычно волнует только тех, кто пишет парсер.
                                      0
                                      А в чём смысл необратимого процесса по созданию валидного кода из невалидного?

                                      Если в конце не стоит цель по созданию валидного кода, то какова конечная цель?
                                        0
                                        тьфу, «невалидного кода из валидного»
                                          +1
                                          Скорее всего, у этого проекта цели вообще нет.

                                          А вот если бы он брал инвалидный хтмл и перпарсивал в валидный, это было бы круто! Весьма.
                                          Но боюсь это почти нереально — слишком много правил парсинга багованных хтмл, причем у всех вьюверов разные и никто о них не рассказывает, особенно Микрософт.
                                            0
                                            описка у меня. :(

                                            надо «невалидного кода из валидного»
                                      0
                                      А как то можно его переносить? я имею ввиду передавать по сети
                                        0
                                        конечно, после трансляции в HTML
                                          0
                                          Т.е. получается что это не переносимый вид шаблона. Я тут пишу свою наработку по переносимым шаблонам — https://github.com/dolphin4ik/synthes (не рекламы ради). Поэтому всегда интересуюсь разными видами шаблонов
                                        +1
                                        Очень как-то коротко. А в чем преимущество данного препроцессора перед jade?
                                          0

                                          NIH же :)

                                          0
                                          Из вашего же примера
                                                   <b>
                                                      Этот текст будет полужирным, 
                                                      <i>а этот — ещё и курсивным</i>
                                                   </b>
                                          

                                          не соответствует
                                                   <b>
                                                      Этот текст будет полужирным, 
                                                      <i>а этот — ещё и курсивным
                                          

                                          Почему тэг i должен закрываться в конце строки, а тэг b — в конце блока, включающего 2 строки? Что если нужно выделить 1 слово, принудительно разрывать строку?

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое