Comments 48
Ага, ищи потом, где у тебя какой тег закончился, если он за границы экрана ушёл или отступов штук 10 будет.
нет, я обрезал HTML не добавляя своих смайликов
А цель была какая? Снизить избыточность HTML, чтобы лишние символы не вводить? Вы пошли в ожидаемом направлении, но остановились на половине пути: например, символы
< и > тоже можно было бы исключить, как это сделали Jade и HAML. В общем, до их уровня емкости кода не дотянули, а вот поддержка редакторов уже потеряна. Поэтому и хуже.
Вопрос, зачем?
Присоединяюсь, следуя логике можно еще написать процессор который удаляет текст, оставляя лишь тэги, или удаляет атрибуты…
Ага в любой современной IDE с использованием автокомплита и, допустим Emmet, никаких преимуществ в скорости набора любого шаблонизатора перед чистым HTML нет, имхо.
У шаблонизаторов другие цели и соответственно другие преимущества.
У шаблонизаторов другие цели и соответственно другие преимущества.
Есть несколько замечаний.
Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.
Зависимость от Codeblocks — это неудобно. Можно использовать CMake в качестве системы сборки. Он более распространен и его проще поставить. CMake сможет сгенерировать проектные файлы и для CodeBlocks, и для VS, а также Makefile для многих ОС и окружений.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.
Зависимость от Codeblocks — это неудобно. Можно использовать CMake в качестве системы сборки. Он более распространен и его проще поставить. CMake сможет сгенерировать проектные файлы и для CodeBlocks, и для VS, а также Makefile для многих ОС и окружений.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
Результаты компиляции (*.o, *.exe) в систему контроля версий класть не следует.
Не первый раз такое читаю, но логичного объяснения никто не даёт, разве что github для кода. При этом хочу отметить что весь код собран в своей папке, бинарники в своей, и если кому-то мешают бинарники, то их легко удалить.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
Опять же, всё легко переписывается, я никому палок в колёса не вставляю.
Не первый раз такое читаю, но логичного объяснения никто не даёт, разве что github для кода. При этом хочу отметить что весь код собран в своей папке, бинарники в своей, и если кому-то мешают бинарники, то их легко удалить.
Имеет смысл сделать опции для указания пути к генерируемому файлу и для вывода результата генерации прямо в stdout.
Опять же, всё легко переписывается, я никому палок в колёса не вставляю.
> Не первый раз такое читаю, но логичного объяснения никто не даёт,
Во-первых, это почти всегда бессмысленно. Если кто-то скачивает исходный код вашего проекта, то он это делает для того, чтобы скомпилировать его из этих исходных кодов. В этом случае артефакты сборки ему совершенно не нужны. Если кому-то нужен exe-файл, то ему при этом не нужны исходники. Для выкладывания готовых файлов на github есть Releases. Кроме того, часто для работы exe-файлы нужны всякие dll-файлы зависимостей (правда, некоторые могут и эти dll в репозиторий добавить). Ну, а объектные файлы почти наверняка никому не пригодятся.
К тому же сборочные файлы могут зависеть от ОС и окружения и могут даже вызвать проблемы со сборкой (файл не пересобирается, потому что он уже есть, но его не получается использовать, т.к. его формат несовместим с текущим окружением).
Во-вторых, это раздувает объем репозитория и заставляет тех, кто работает с вашим кодом, скачивать ненужные им файлы. Размеры exe-файлов в дебажных сборках запросто достигают десятков мегабайт, а ведь система контроля версий будет хранить все закоммиченные версии этих файлов, и репозиторий быстро вырастет до ужасных размеров.
В-третьих, бинарные файлы будут изменяться с каждым изменением кода и будут засорять историю изменений, ради которой система контроля версий и затевается. Хочется, глядя на коммит, быстро увидеть, какие файлы в нем изменились, и постоянные бессмысленные изменения бинарных файлов в каждом коммите будут очень мешать.
Во-первых, это почти всегда бессмысленно. Если кто-то скачивает исходный код вашего проекта, то он это делает для того, чтобы скомпилировать его из этих исходных кодов. В этом случае артефакты сборки ему совершенно не нужны. Если кому-то нужен exe-файл, то ему при этом не нужны исходники. Для выкладывания готовых файлов на github есть Releases. Кроме того, часто для работы exe-файлы нужны всякие dll-файлы зависимостей (правда, некоторые могут и эти dll в репозиторий добавить). Ну, а объектные файлы почти наверняка никому не пригодятся.
К тому же сборочные файлы могут зависеть от ОС и окружения и могут даже вызвать проблемы со сборкой (файл не пересобирается, потому что он уже есть, но его не получается использовать, т.к. его формат несовместим с текущим окружением).
Во-вторых, это раздувает объем репозитория и заставляет тех, кто работает с вашим кодом, скачивать ненужные им файлы. Размеры exe-файлов в дебажных сборках запросто достигают десятков мегабайт, а ведь система контроля версий будет хранить все закоммиченные версии этих файлов, и репозиторий быстро вырастет до ужасных размеров.
В-третьих, бинарные файлы будут изменяться с каждым изменением кода и будут засорять историю изменений, ради которой система контроля версий и затевается. Хочется, глядя на коммит, быстро увидеть, какие файлы в нем изменились, и постоянные бессмысленные изменения бинарных файлов в каждом коммите будут очень мешать.
>Было принято решение написать препроцессор HTML
А самое интересное вы в статье так и не упомянули, что же все таки привело к принятию такого решения.
А самое интересное вы в статье так и не упомянули, что же все таки привело к принятию такого решения.
Okay, вот вам HTML:
<b>Bold <i>Bold italic </b>Italic</i>Что там на выходе будет?
UFO just landed and posted this here
Что значит garbage? Это корректный HTML (хотя, конечно, некорректный XML). И он прекрасно показывается всеми браузерами.
>Это корректный HTML
Справедливости ради, то что он прекрасно показывается (а всеми ли? тысячи же их) браузерами, не значит что он корректный. Собственно если, хотите говорить о корректности, то начните уж с доктайпа и с того что он w3c хотябы без ошибок проходит.
Справедливости ради, то что он прекрасно показывается (а всеми ли? тысячи же их) браузерами, не значит что он корректный. Собственно если, хотите говорить о корректности, то начните уж с доктайпа и с того что он w3c хотябы без ошибок проходит.
UFO just landed and posted this here
Есть валидатор: https://validator.w3.org/#validate_by_input+with_options
В общем случае суем туда весь документ и смотрим на количество Errors, если они есть, то хтмл обычно считается не валидным, там же будет описание, довольно подробно, почему.
warnings тоже указывают на некоторые проблемы, но не все считают это признаком невалидности, мне тоже кажется, что там есть спорные.
Однако тут есть нюанс, валидация по сути основывается на doctype и рассматривать валидность документа можно только в контексте его.
Кстати тут есть такой прикольный момент, в целом можно создать свой doctype обозначить там свои правила и это тоже будет некий «валидный хтмл». И кстати, вполне возможно, что через это можно создать некий minHTML, без всяких левых препроцессоров.
В общем случае суем туда весь документ и смотрим на количество Errors, если они есть, то хтмл обычно считается не валидным, там же будет описание, довольно подробно, почему.
warnings тоже указывают на некоторые проблемы, но не все считают это признаком невалидности, мне тоже кажется, что там есть спорные.
Однако тут есть нюанс, валидация по сути основывается на doctype и рассматривать валидность документа можно только в контексте его.
Кстати тут есть такой прикольный момент, в целом можно создать свой doctype обозначить там свои правила и это тоже будет некий «валидный хтмл». И кстати, вполне возможно, что через это можно создать некий minHTML, без всяких левых препроцессоров.
Ок, про корректность я, конечно, погорячился. Но как тогда назвать HTML, который должны показывать (одинаково при этом) все нормальные браузеры? Помнится, когда-то (достаточно давно) я тоже писал свой микро-браузер, и с парсингом подобных конструкций тоже намаялся (равно как и с возможным отсутствием некоторых закрывающих тегов). Корректно это? Нет. Так пишут только *удаки? Да. Надо ли это показывать? Увы, да.
>Но как тогда назвать HTML, который должны показывать
>(одинаково при этом) все нормальные браузеры?
Так логично же, что валидным или корректным хтмл например.
Штука в том, что то что написали вы они показывать корректно не должны, хоть возможно и показывают, это собственно вообще не хтмл, это строчка неких символов.
>(одинаково при этом) все нормальные браузеры?
Так логично же, что валидным или корректным хтмл например.
Штука в том, что то что написали вы они показывать корректно не должны, хоть возможно и показывают, это собственно вообще не хтмл, это строчка неких символов.
Я полистал спецификацию, и там такой случай таки упоминается и даже рассказывается как лучше исправлять. Хотя валидатор ругается, не знаю что и думать
Вот вам тогда такой HTML:
Где после кастрации препроцессором будет кончаться курсив, а где болд?
<b>Bold
<i>Bold
italic</i>
Ita</b>
lic
Где после кастрации препроцессором будет кончаться курсив, а где болд?
Так в хтмл и так можно не писать закрывающийся тег:
<p>Hello,
<p>world!Как только замечен новый открывающийся тег — предыдущий закрывается.
*промахнулся deleted
Это разве статья?
Jade вам в помощь.
https://habrahabr.ru/post/278109/
https://habrahabr.ru/post/278109/
Не нашел в коде правил стандартного автозакрытия тегов.
Мнение валидатора уже не важно?
Валидатор обычно волнует только тех, кто пишет парсер.
А в чём смысл необратимого процесса по созданию валидного кода из невалидного?
Если в конце не стоит цель по созданию валидного кода, то какова конечная цель?
Если в конце не стоит цель по созданию валидного кода, то какова конечная цель?
тьфу, «невалидного кода из валидного»
Скорее всего, у этого проекта цели вообще нет.
А вот если бы он брал инвалидный хтмл и перпарсивал в валидный, это было бы круто! Весьма.
Но боюсь это почти нереально — слишком много правил парсинга багованных хтмл, причем у всех вьюверов разные и никто о них не рассказывает, особенно Микрософт.
А вот если бы он брал инвалидный хтмл и перпарсивал в валидный, это было бы круто! Весьма.
Но боюсь это почти нереально — слишком много правил парсинга багованных хтмл, причем у всех вьюверов разные и никто о них не рассказывает, особенно Микрософт.
А как то можно его переносить? я имею ввиду передавать по сети
Очень как-то коротко. А в чем преимущество данного препроцессора перед jade?
Из вашего же примера
не соответствует
Почему тэг i должен закрываться в конце строки, а тэг b — в конце блока, включающего 2 строки? Что если нужно выделить 1 слово, принудительно разрывать строку?
<b>
Этот текст будет полужирным,
<i>а этот — ещё и курсивным</i>
</b>
не соответствует
<b>
Этот текст будет полужирным,
<i>а этот — ещё и курсивным
Почему тэг i должен закрываться в конце строки, а тэг b — в конце блока, включающего 2 строки? Что если нужно выделить 1 слово, принудительно разрывать строку?
Sign up to leave a comment.
Небольшой препроцессор HTML