Здравствуйте, sambl74, Вы писали:
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
S>Ну вообще-то он есть — https://ru.wikipedia.org/wiki/SSI_(программирование)
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
есть же document.write
есть же tag.innerHTML | tag.innerText
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Здравствуйте, vsb, Вы писали:
S>>Какие были инженерные резоны против такого решения?
vsb>Вероятно маленький спрос на такую фичу.
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
vsb>Вероятно не такая уж и изрядная.
Ну уж, футеры-то с копирайтом есть на каждом сайте.
Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
Здравствуйте, Lazytech, Вы писали:
S>>Все эти теневые деревья убивают саму идею.
L>Напомню, идея в изоляции от остального HTML-кода.
Идея #include в файлизме, как это называл один знакомый. Юниксовая концепция, что всё — в том числе, шаблон для вставки — есть файл. (Там даже устройства — файлы, что уж говорить про шаблоны). Зачем же изолировать вставленный из файла фрагмент? Наоборот, в соответствии с этой концепцией, он должен бесшовно вписаться в DOM. Ну, как это, собственно, и происходит в Си.
Здравствуйте, Shtole, Вы писали:
S>Ну уж, футеры-то с копирайтом есть на каждом сайте.
S>Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
Здравствуйте, night beast, Вы писали:
S>>Ну уж, футеры-то с копирайтом есть на каждом сайте.
S>>Между прочим, Майкрософт прикрутил колонтитулы к офисным документам очень рано. В 95-м офисе, кажется. И это для сиволапых юзеров. Была, значит, у них потребность в DRY. А тут — инженеры, умеющие в разметку, и у них не возникло потребности в более удобном структурировании на раннем этапе развития HTML? Вот это меня и удивляет.
NB>ну, были всякие frameset, или ты про другое?
Фреймы дают ту самую (непрошенную) изоляцию, обсуждаемую выше. На практике это значит, что (например) нельзя шаблонизировать пол-элемента. Хотя это может быть исключительно сложно устроенный элемент.
Здравствуйте, ·, Вы писали:
S>>Какие были инженерные резоны против такого решения? ·>frame/iframe разве не оно?
S>Фреймы дают ту самую (непрошенную) изоляцию, обсуждаемую выше. На практике это значит, что (например) нельзя шаблонизировать пол-элемента. Хотя это может быть исключительно сложно устроенный элемент.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Сейчас большинство сайтов собираются программами-сборщиками (WebPack, Vite, gulp — их тьма) из исходников (причем даже статических HTML сайтов). Вот там и делается этот #include из разных исходников с обработкой CSS и рендерингом шаблонов, а также "перетряской дерева" для минимизации размера страницы (и довольно эффективно, если разработчики уделяют этому внимание). При отдаче контента #include не даст пользы (ну, или опиши реальную ситуацию, где #include в HTML по сети с клиента будет полезен).
Здравствуйте, Reset, Вы писали:
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
R>Сейчас большинство сайтов собираются программами-сборщиками (WebPack, Vite, gulp — их тьма) из исходников (причем даже статических HTML сайтов). Вот там и делается этот #include из разных исходников с обработкой CSS и рендерингом шаблонов, а также "перетряской дерева" для минимизации размера страницы (и довольно эффективно, если разработчики уделяют этому внимание). При отдаче контента #include не даст пользы (ну, или опиши реальную ситуацию, где #include в HTML по сети с клиента будет полезен).
Мне больше интересно в ретроспективе. HTML ведь появился очень давно.
Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
S>Мне больше интересно в ретроспективе. HTML ведь появился очень давно.
Я практик и прагматик. Такое мне не интересно.
S>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
