К сравнению:
<!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>а этот — ещё и курсивным
Второй, на мой взгляд, короче, быстрее набирается, легче читается и правится.
Код транслятора здесь, инструкция прилагается.
Комментарии (46)
impwx
20.10.2016 14:44+15
Lex20
20.10.2016 15:57-4нет, я обрезал HTML не добавляя своих смайликов
impwx
20.10.2016 16:12+2А цель была какая? Снизить избыточность HTML, чтобы лишние символы не вводить? Вы пошли в ожидаемом направлении, но остановились на половине пути: например, символы
<и>тоже можно было бы исключить, как это сделали Jade и HAML. В общем, до их уровня емкости кода не дотянули, а вот поддержка редакторов уже потеряна. Поэтому и хуже.
tmnhy
20.10.2016 14:59+2Вопрос, зачем?
token
20.10.2016 15:01+1Присоединяюсь, следуя логике можно еще написать процессор который удаляет текст, оставляя лишь тэги, или удаляет атрибуты…
AYShestakov
20.10.2016 19:54+1Ага в любой современной IDE с использованием автокомплита и, допустим Emmet, никаких преимуществ в скорости набора любого шаблонизатора перед чистым HTML нет, имхо.
У шаблонизаторов другие цели и соответственно другие преимущества.
Riateche
20.10.2016 15:01Есть несколько замечаний.
Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.
Зависимость от Codeblocks — это неудобно. Можно использовать CMake в качестве системы сборки. Он более распространен и его проще поставить. CMake сможет сгенерировать проектные файлы и для CodeBlocks, и для VS, а также Makefile для многих ОС и окружений.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.Lex20
20.10.2016 15:50-5Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.
Не первый раз такое читаю, но логичного объяснения никто не даёт, разве что github для кода. При этом хочу отметить что весь код собран в своей папке, бинарники в своей, и если кому-то мешают бинарники, то их легко удалить.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
Опять же, всё легко переписывается, я никому палок в колёса не вставляю.Riateche
20.10.2016 16:08+6> Не первый раз такое читаю, но логичного объяснения никто не даёт,
Во-первых, это почти всегда бессмысленно. Если кто-то скачивает исходный код вашего проекта, то он это делает для того, чтобы скомпилировать его из этих исходных кодов. В этом случае артефакты сборки ему совершенно не нужны. Если кому-то нужен exe-файл, то ему при этом не нужны исходники. Для выкладывания готовых файлов на github есть Releases. Кроме того, часто для работы exe-файлы нужны всякие dll-файлы зависимостей (правда, некоторые могут и эти dll в репозиторий добавить). Ну, а объектные файлы почти наверняка никому не пригодятся.
К тому же сборочные файлы могут зависеть от ОС и окружения и могут даже вызвать проблемы со сборкой (файл не пересобирается, потому что он уже есть, но его не получается использовать, т.к. его формат несовместим с текущим окружением).
Во-вторых, это раздувает объем репозитория и заставляет тех, кто работает с вашим кодом, скачивать ненужные им файлы. Размеры exe-файлов в дебажных сборках запросто достигают десятков мегабайт, а ведь система контроля версий будет хранить все закоммиченные версии этих файлов, и репозиторий быстро вырастет до ужасных размеров.
В-третьих, бинарные файлы будут изменяться с каждым изменением кода и будут засорять историю изменений, ради которой система контроля версий и затевается. Хочется, глядя на коммит, быстро увидеть, какие файлы в нем изменились, и постоянные бессмысленные изменения бинарных файлов в каждом коммите будут очень мешать.staticlab
20.10.2016 16:19+4В четвёртых, при мёржах веток будут постоянно возникать конфликты.
В-пятых, если исходник был изменён без пересборки, то будет несоответствие версий.
jrip
20.10.2016 15:19+4>Было принято решение написать препроцессор HTML
А самое интересное вы в статье так и не упомянули, что же все таки привело к принятию такого решения.Lex20
20.10.2016 16:07-3Внимательно читайте статью:
Второй, на мой взгляд, короче, быстрее набирается, легче читается и правится.jrip
20.10.2016 16:17Т.е. у вас была проблема с быстрым набором, прочтением и исправлением html и вы решили ее созданием своего «minHTML», вместо, например использования макросов в IDE? миленько :)
hdfan2
20.10.2016 15:35Okay, вот вам HTML:
<b>Bold <i>Bold italic </b>Italic</i>
Что там на выходе будет?
izzholtik
20.10.2016 15:47+1https://ru.wikipedia.org/wiki/GIGO
hdfan2
20.10.2016 15:50-4Что значит garbage? Это корректный HTML (хотя, конечно, некорректный XML). И он прекрасно показывается всеми браузерами.
jrip
20.10.2016 16:06+3>Это корректный HTML
Справедливости ради, то что он прекрасно показывается (а всеми ли? тысячи же их) браузерами, не значит что он корректный. Собственно если, хотите говорить о корректности, то начните уж с доктайпа и с того что он w3c хотябы без ошибок проходит.izzholtik
20.10.2016 18:02А действительно, как такие спорные ситуации разрешать? Можете ткнуть носом в документ?
jrip
20.10.2016 18:48Есть валидатор: https://validator.w3.org/#validate_by_input+with_options
В общем случае суем туда весь документ и смотрим на количество Errors, если они есть, то хтмл обычно считается не валидным, там же будет описание, довольно подробно, почему.
warnings тоже указывают на некоторые проблемы, но не все считают это признаком невалидности, мне тоже кажется, что там есть спорные.
Однако тут есть нюанс, валидация по сути основывается на doctype и рассматривать валидность документа можно только в контексте его.
Кстати тут есть такой прикольный момент, в целом можно создать свой doctype обозначить там свои правила и это тоже будет некий «валидный хтмл». И кстати, вполне возможно, что через это можно создать некий minHTML, без всяких левых препроцессоров.
hdfan2
21.10.2016 10:27Ок, про корректность я, конечно, погорячился. Но как тогда назвать HTML, который должны показывать (одинаково при этом) все нормальные браузеры? Помнится, когда-то (достаточно давно) я тоже писал свой микро-браузер, и с парсингом подобных конструкций тоже намаялся (равно как и с возможным отсутствием некоторых закрывающих тегов). Корректно это? Нет. Так пишут только *удаки? Да. Надо ли это показывать? Увы, да.
jrip
21.10.2016 11:12>Но как тогда назвать HTML, который должны показывать
>(одинаково при этом) все нормальные браузеры?
Так логично же, что валидным или корректным хтмл например.
Штука в том, что то что написали вы они показывать корректно не должны, хоть возможно и показывают, это собственно вообще не хтмл, это строчка неких символов.
galaxy
20.10.2016 16:37-1Вот вам тогда такой HTML:
<b>Bold <i>Bold italic</i> Ita</b> lic
Где после кастрации препроцессором будет кончаться курсив, а где болд?
muxa_ru
20.10.2016 16:35Мнение валидатора уже не важно?
Durimar123
20.10.2016 16:41+1Валидатор обычно волнует только тех, кто пишет парсер.
muxa_ru
20.10.2016 16:46А в чём смысл необратимого процесса по созданию валидного кода из невалидного?
Если в конце не стоит цель по созданию валидного кода, то какова конечная цель?Durimar123
20.10.2016 17:19+1Скорее всего, у этого проекта цели вообще нет.
А вот если бы он брал инвалидный хтмл и перпарсивал в валидный, это было бы круто! Весьма.
Но боюсь это почти нереально — слишком много правил парсинга багованных хтмл, причем у всех вьюверов разные и никто о них не рассказывает, особенно Микрософт.
dolphin4ik
20.10.2016 18:11А как то можно его переносить? я имею ввиду передавать по сети
Lex20
20.10.2016 19:16конечно, после трансляции в HTML
dolphin4ik
20.10.2016 22:28Т.е. получается что это не переносимый вид шаблона. Я тут пишу свою наработку по переносимым шаблонам — https://github.com/dolphin4ik/synthes (не рекламы ради). Поэтому всегда интересуюсь разными видами шаблонов
fallen_trancer
20.10.2016 19:40+1Очень как-то коротко. А в чем преимущество данного препроцессора перед jade?
Smi1e
20.10.2016 21:00Из вашего же примера
<b> Этот текст будет полужирным, <i>а этот — ещё и курсивным</i> </b>
не соответствует
<b> Этот текст будет полужирным, <i>а этот — ещё и курсивным
Почему тэг i должен закрываться в конце строки, а тэг b — в конце блока, включающего 2 строки? Что если нужно выделить 1 слово, принудительно разрывать строку?
sHinE
Ага, ищи потом, где у тебя какой тег закончился, если он за границы экрана ушёл или отступов штук 10 будет.