Low cost CMS

Еще это все можно пихнуть в svg и гипертекстовый фидонет готов.

Браузеры может и умеют, а поисковики и всяческие соц сети, которые виджет сайта отображают?

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

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

не знаю и знать не хочу

Это когда ты в мессенджер или в заблокированбук кидаешь ссылку, а у получателя помимо ссылки отображается краткое саммари того что по ссылке

Open Graph

А минусы будут?

this

Делаем странички в XML.

Не проще на голом html писать оно-же по сули XML

у получателя помимо ссылки отображается краткое саммари того что по ссылке

ИЧСХ отключить эту порнографию нельзя

Не проще на голом html писать оно-же по сули XML

Надо же на куче страниц более-менее одинаковый хедер и прочую структуру. В HTML такого нет без JS.

все уже было придумано до тебя http://thalassa.croco.net/

Делаем странички в XML.

К ним прикручиваем XSLT, который переводит наш XML в XHTML.

Всё это отдаём тупо статикой, без всякой генерации. Браузеры умеют в XSLT. Промежуточных шагов нет.

Зачем столько промежуточных шагов? Делай страницы сразу в html (не xhtml - это гадость) и отдавай статикой.

Нет, html это не xml, он, в отличие от xml, поддерживает теги без вложенной структуры (<br>, а в xml оно только <br/>).

Я к тому что усилия на написание xml сравнимы с голым html, зачем лишнюю работу делать если можно сразу с html писать?

Шаблонизатором добавлять?

Для этого надо какой-то софт ставить, или на этапе сборки, или на этапе отдачи контента. Это неудобно.

А смысл? Взял php, он уже шаблонизатор, сделал php index.php > index.html и залил по FTP.

Намного проще и удобнее.

Бери doxygen pandoc он из чего хочешь тебе сайт сварганит

Надо же на куче страниц более-менее одинаковый хедер и прочую структуру

SSI.

Опять всё перепутал. Гадость это HTML5, а XHTML - похоронённое гуглом светлое будущее.

Требовать писать <br/> вместо <br> - это идиотизм. Единственная причина придумывания этой ерунды - упростить написание парсеров, ценой превращения языка в язык для роботов, а не людей. Суть html в том, что это текст с добавленной к нему разметкой, не обязанной быть корректной ни в каком аспекте, а браузер должен пытаться максимально угадать что хотел кодописатель.

XSLT

XML

XHTML

Взять какой-нибудь gohugo и хранить контент в Markdown, движок сам сгенерит статику и никакой наркомании со структурой XML/HTML, просто работает.

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

Ты изобрёл статический генератор сайтов. У меня такой генератор на bash генерирует мне сайт. Текст укладывается в txt, картинки как есть, скрипт их находит, рендерит и отправляет на хостинг через ssh.

Есть некоторое количество генераторов сайтов на ansible, например, потому что в ansible встроен шаблонизатор jinja2. Ну или просто генераторы.

P.S. Самая первая прямая линия с В. Путиным, транслируемая на сайте Яндекса, была сделана именно так, как ты пишешь — через генерацию HTML при помощи XSLT. Сайт обновлялся примерно раз в 30 секунд и счётчик на js добавлял новые данные на страницу, поэтому у посетителя возникало ощущение, что страница обновляется динамически. Но на самом деле это была статическая статика — иначе сервера бы не выдержали.

движок

«Low cost CMS»

Он хочет бюджетный движок, вплоть до полного его (движка) отсутствия. «Движок» на стороне клиента - xslt трансляция средствами браузера.

бюджетный движок, вплоть до полного его (движка) отсутствия

Сказочный наркоман! (=

Сказочный наркоман! (=

Если жив и здоров, то чем нереальнее, сказочнее остальных?

Т.е. без JavaScript? Типа такого https://www.yegor256.com/2014/06/25/xml-and-xslt-in-browser.html

Кстати у меня их demo страничка (https://www.stateful.co/) в FireFox не отработала.

Или с применением JS (через XSLTProcessor)?

Сразу минусы:

1. если какая-нибудь ошибка в xml/xslt, то сайт упадет. html, в отличии от xml/xhtml, прощает ошибки;
2. если изменилась ссылка на страницу в навигации, то придется эту ссылку править во всех xml. Генераторы сайтов умеют править навигацию везде, если где-то изменилась ссылка;
3. перекладываешь генерацию html в браузер. Может такая ситуация, что чел с телефона/старого компа тупо не сможет открыть страницу, так как ресурсы выжрало преобразование xml в html;
4. не все браузеры этим будут заниматься, так как каких-нибудь разерешений у них нет. Скорее всего юзеру будет отдаваться голая xml.

Если измерять стоимость в количестве времени, то это прям high cost CMS получается.

А минусы будут?

Напиши несколько хслт трансформаций.

Проблема с этим была в том, что каждый браузер по-своему угадывал что хотел сказать пользователь, пока в html5 не догадались стандартизировать механизм угадывания. Стандарт получился сложным, парсер тоже. Если б победил xhtml, то был бы таким же простым как в xml.

Т.е. без JavaScript? Типа такого https://www.yegor256.com/2014/06/25/xml-and-xslt-in-browser.html

Да, без JS. Ну т.е. отсутствие JS это не самоцель, это конкретно для этого функционала отсутствие. Можно и с JS, но тогда обсуждать будет нечего.

Проблема с этим была в том, что каждый браузер по-своему угадывал что хотел сказать пользователь,

Проблемы тут нет. Она в головах у тех, кто вместо размеченного текста хочет показывать юзерам гуи-приложение с попиксельной точностью.

Если б победил xhtml, то был бы таким же простым как в xml.

Такая «простота»-тупизна не нужна. Писатели парсеров тут в «услужении» у писателей сайтов, а не наоборот. Поэтому парсер будет настолько сложным, насколько это надо для показа всего того, что написали в том числе далёкие от it люди, кое-как научившись вставлять в текст теги <b> <i> <u> <table>. А xhtml придумали теоретики-вредители, которые хотят кодить ради кодинга.

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

Такая «простота»-тупизна не нужна

А как же бесконечные треды что веб пошёл куда-то не туда, стал безумно сложным, из браузерных движков осталось ровно два, и второй вот-вот сдохнет.

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

Главное чтобы текст, который юзер хотел показать, не потерялся. А если браузер не сможет распарсить неправильно размеченную таблицу и засунет всё её содержимое в одну ячейку, или вообще оставит просто текстом - ну, неприятно, но читать можно.

А как же бесконечные треды что веб пошёл куда-то не туда, стал безумно сложным, из браузерных движков осталось ровно два, и второй вот-вот сдохнет.

Эта безумная сложность как раз там, где пытаются вместо размеченного текста делать гуи-приложения.

Есть такая технология древних, <frame>. Там тоже хедер-футер можно один раз наверстать. Технология не без минусов.

Можно ещё все тексты хедеров-футеров в css запихнуть с помощью свойства content.

Но проще всего конечно сгенерить все html файлы заранее из исходников шаблонизаторами.

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

xml не для людей (не читайм), и не для машин (медленый), это единственно, что меня отталкивает.
по факту очень интересно, кто то из создателей этого чуда его где то использовал (на практике)? подозреваю проще юзать тупой str_replace для почти готового HTML.

Кто использовал XML на практике? Ну я каждый день использую, например. И для людей прекрасно читаем и для машин вроде нормально, хз, что ты там медленного нашёл, уж точно не медленней богопротивного JSON.

в явасране везде конфиги на кунимель этом, в то время как в нориальных языках yaml, toml или на худой конец - json с комментариями (jsonc)

Ну тут никуда не деться, но распарсить одиночный тег всё-таки задача простая - там главное убедиться что не потерялось закрывающее > и что внутри проблем с кавычками нет. Парные теги скриптов/стилей - тоже. Кстати, после script src= я бы в целях упрощения не ждал никаких </script> а парсил всё что после как html.

Оно всё простое, пока не сталкиваешься с реальным миром. Там во всех комбинациях будет ерунда. Собственно xhtml это был один способ это решить, тупо показать на весь экран ошибку, пока сайтодел не удосужится поправить. Html5 это другой способ, стандартизированный best effort, сайтоделу тоже придётся поправить, но он теперь не сможет ссылаться что в его браузере всё работает.

Если ты считаешь что в html4 не было проблем, надо было оставлять как есть, и парсить как кому нравится, что пользователь всё равно что надо прочитает, ну.. добро пожаловать обратно в 2005, я пожалуй в 2025 останусь, мне тут лучше.

Можно взять какой-нибудь Hugo и не придумывать костыли.

Я как раз обратный подход говорю: сайтодела ничего заставлять не надо. Если сайтодел хочет проверить сайт на ошибки - он может локально у себя проверить строгость синтаксиса итд. А дальше, вне зависимости от того, проверил он или нет, корректный там код или нет, браузер ДОЛЖЕН показать максимально информативное содержние из того, что он сможет. Никаких жалоб на «сайтодел плохой, не буду работать» тут быть ни в коем случае не должно, такой браузер - бракованный. Юзер зашёл на сайт - он хочет прочитать его содержимое, задача браузера предпринять максимальные усилия, чтобы это желание юзера удовлетворить. Да, если там свосем плохо, можно выдать варнинг: «мы очень старались, но распарсить часть страницы не вышло и, возможно, какую-то часть сайта вы не видите».

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

Да ты что? Тут есть два варианта того, что будет делать сайтодел. Когда юзер пришлёт ему репорт о проблеме (и не важно, заметил ли её синтаксически браузер или не заметил, проблема может быть и не в синтаксисе), сайтодел решит, важна ли она для него или нет. Если да - он исправит так чтобы юзер проблему больше не испытывал. Если нет - он пошлёт юзера нафиг со словами «УМВР». Заметь, ему в обоих случаях будет 100% плевать на все эти html5, xml и прочие технические подробности.

он исправит так чтобы юзер проблему больше не испытывал

Чтобы исправить, ему нужен именно тот браузер, именно с той интерпретацией неоднозначностей html, что у пользователя.

То есть сайтодел никогда не будет исправлять ошибку. Скажет: скачай такой же дефолтный браузер, что у меня. Безусловный УМВР. Что и видим в последнее время: ваш браузер устарел скачайте правильную версию по этой ссылке (куда ведет эта ссылка?)

Не было у html никаких фатальных неоднозначностей. Нигде не было расхождений вида «один браузер считает что это продолжается тег, а другой считает что тут уже текст». Было разве что такое, что pre-js браузеры показывали js в качестве контента страницы, если js-писатель не обернул его в <!-- -->. Ну, это тоже не сильно критично, ведь страница, рассчитанная на js, в браузере без js скорее всего всё равно будет работать немного не так как запланировано.

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

ваш браузер устарел скачайте правильную версию по этой ссылке (куда ведет эта ссылка?)

Я такие штуки либо игнорирую, либо меняю юзерагент если сайт злонамеренно ломается.

Я не эксперт в html, но там проблема в том, как интерпретировать, если влезает «неожиданный» (закрывающий) тег.

меняю юзерагент если сайт злонамеренно ломается.

Такие сайты спецом пишутся так, чтобы ломались, если неправильный браузер. Смена юзерагнета не исправит неправильную интепретацию специального html. Это сродни написанию вирусов/взлома. Сложный неоднозначный парсинг - это широкий простор для взлома.

недавно пишущий протокол сервер для xmpp проклинал, схема XML менается в зависимости от значения поля, 100 схем сразу применять, или регуляркой отловить и потом нужное использовать.
Ладно в xmpp XML не очень подходит, половину сообщения получили использовать не сможем, пускай пользовотель ожидает когда всё придёт.
В библиотечной системе где вроде XML самое то, поиск занимает время более 2 часов, в json секунды. (база pgsql работа с xml, и json средствами pg)
В javascript где работа в формате xml изначально была, все перешли на хак с eval юзать json.
Для конфига юзать xml попробуй в конфиге гнома найти что либо, ошибится в конфиге апача, что вообщето не xml, но навеян им, гораздо проще чем в nginx.
Писал голосового помошника, останавливать его и запускать при изменении конфига, добавлении новой команды, конфиг при изменении даты, парсится перед распознании лексем и меняется при работе например команды для работы в режиме музыки или майнкрафта, долго парсить не вариант.

где XML применим, не создаёт проблем?

Нет там проблемы. Во-первых, вне зависимости от интерпретации, текст никуда не пропадёт, максимум он переместится в другое место или сменит стиль. Во-вторых, неожиданные закрывающие теги всегда игнорировались. Неожиданный - это когда тега <b> нигде нет, но есть тег </b>. Если же ты про неожиданный в плане того, что он ожидается, но не сейчас (<table><tr><td>123</table>), то тут тоже всё понятно: таблица заканчивается, значит ячейка и строка её тоже заканчиваются.

У меня смена юзерагента во всех случаях помогала.

браузер ДОЛЖЕН показать максимально информативное содержние из того, что он сможет

Это то что делает html5, best effort. Я там говорил что важно чтобы этот best effort был везде одинаковый, а не в каждом браузере свой.

Тут есть два варианта того, что будет делать сайтодел.

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