Comments 37
Это были 90е, мы выживали как могли (=
Минимально валидная страница в Хроме:
<title></title>
а не body /body?
Этот тег необязателен :D
Хром минимальный DOM сам достраивает.
<code><filetype="BUBLIK"!!!>
<picture="center">
<hat>
<color="red"></color>
</hat>
<cat>
<color="dark","brown","white"></color>
</cat>
Всем привет! Мурррр, мяу! :)
</dark></brown></white>
</picture></code>
нет, это называется html fragment, и это валидный html.
На самом деле вместо title может быть любой тэг, например <div></div>
Армянское радио спросили: «Может ли змея сломать позвоночник?». Армянское радио ответило: «Да. Если она будет строго придерживаться партийной линии».
Ещё совсем недавно за такое: onclick="this.classList.add('bg-green')"> просто убивали из рогатки. Теперь это, оказывается, желательно.
Я бы предложил не следовать слепо чьим-то придуманным правилам, а решать для себя, чего и как вы хотите добиться. В данном случае стоит спросить себя, почему выбор стоит между
<button onclick="this.classList.add('bg-green')">
Click Me
</button>
и
var resultsPane = document.getElementById("results-pane");
resultsPane.addEventListener("click", function() {
this.classList.add("active");
});
Как говорил товарищ Сталин, «Оба уклона у вас какие-то левые».
В первом случае, очевидно, код гораздо проще и понятнее, чем во втором. Но лично для меня этого недостаточно, чтобы он был «желательнее».
Почему HTML так хорош? Потому что он не монолитен, как все остальные платформы (от JavaFX до Qt), а разбит аж на четыре DSL'я. Это был фактор победы, поэтому когда я вижу, как кто-то снова их смешивает, я понимаю, что это реакционное движение, и оно не может быть верным. Разметка это разметка, и негоже пихать туда ни оформление (да-да, я про бездумное применение Tailwind'а), ни манипуляцию DOM'ом, как в примере выше, возвращаясь в век атрибутов.
Второй код, конечно, ужасен, потому что избыточен. Вот так он не сложнее первого:
$('results-pane').on('click', () => $(this).addClass('active'));
В результате, вся установка триггеров оказывается собрана в одной секции (или нескольких, но это уж как требуется по логике работы), и эта секция отделена от разметки. И установка не менее проста, чем в первом случае.
А ещё лучше подумать, как декларативно выразить эту логику, а такое уже не грех и в атрибуты пихать. Например, [data-]class-on-click.
Ах да, авторы HTML First же нам запретили использовать что-то, кроме ванилина. А доллар не ванильный. Что я могу сказать? Если ребята из Гугла никак не добавят в свой браузер поддержку декларативного $(), то это, как бы, их проблемы. Лично я предпочитаю браузерные движки, где $() входит в стандартную библиотеку скриптового DSL'я, но если надо писать под Хромиум или браузеры общего назначения (те, которые юзеры запускают сами), я всё равно не буду уродовать код императивным многословием ради какой-то абстрактной ванильности.
P.S. И ориентироваться на то, какой там код пишет Гугл в 2023 году я бы не стал. Вы не гугл.
() => $(this)
Контекст (или как там оно называется) у стрелочных, насколько помню, не передаётся. Поэтому лучше function(), чем потом с event заморачиваться.
Так да, с вами согласен. Мы делили-делили на типы файлов, модули и т.д. ради чистоты кода и объединения задачь по областям. Декомпозицию делали. А мешать опять все в одну кучу - спасибушки.
Вот за этот this.classList.add('bg-green') я тоже сразу зацепился. Один из главных принципов "молодого HTML" - семантика. Не надо тащить в html-структуру страницы обработку логики (пусть это и логика представления) - для этого есть js. По onclick вопрос дискуссионный.
На самом деле многое зависит от масштабов проекта. В небольших проектах действительно бывает удобнее вынести какую-то примитивную логику представления в html-структуру, просто чтобы "не плодить сущности без нужды".
Кстати, если убрать onclick и добавить $() и [data-]class-on-click то получается самый настоящий jQuery-style))
что касается поддержки $, ну напишите
if(!$) $ = document.querySelectorAll;
И как всегда свидетели jqwery любят притягивать крайние случаи
Для первого случая хватит самого обычного js вот так:
<button onclick="setClass(this, 'bg-green')">
Click Me
</button>
Где весь функционал будет в отдельном методе и в случае чего так же с одного места патчатся краевые условия.
.
Второй случай для ситуаций обработки сценариев, зачастую это все собирается конструктором и для кучи разных елементов. В коде выглядит как инициализация метода класса.
И даже если писать ручками - один хрен такой формат записи подходит больше именно для централизованой обработки всех событий
.
А теперь подходим к моему самому "любимому"
Свидетели jqwery - они записи формата $('results-pane').* раскидывают как обезьяна какашки.
Ладно 10+ лнт назад это было проще изяшнее чем то что позволял движок js на тот момент, но на сейчас старые костыли стали фичей говностроения.
Да - любым средсвом нужно уметь пользоватся, но как раз именно поддержка упрощенного синтаиса через $ очень сильо понижает требования к коду
.
Из жизни - если большой проект который лепили и дополняли хотя-бы пару лет при использовании jqwery, то добавление критично нового функционала зачастую вылазит в переписывание всей страницы.
Потому что можно "по быстрому" насыпать $ и не переживать так как внутрение конфликты jqwery разрешает сам. Быстро и удобно - самое то для разработки. А поддержка и расширение - ну это сложная задача, требуюшая много трудозатрат
.
Может мое мнение субьективное - я с фронт-ендерами просто плотно работаю, но я никогда не встречал решений на jqwery в ситуациях с "нормально делай - нормально будет"
А за гугл соглашусь - он уже лет 10 не торт, а его ресурсы не проходят его же тесты что он выкладывает в открытый доступ)
>> Почему HTML так хорош?
ИМХО, самая глубинная причина хорошести html-а кроется в особенностях человеческого зрения. Наш глаз не идеален и текст должен быть очень удобен для восприятия его им. Например, нельзя увеличить текст в два раза - нужно обязательно изменить его пропорции. К этому еще добавляется и неидеальность даже современных мониторов: буквы могут размыться, у них может появится цветной ореол, могут стать угловатыми и т.д.
Поэтому нельзя изначально знать, сколько места текст займет на экране, и все остальные элементы должны подстроиться под него только во время отрисовки. Было множество попыток упростить вывод на экран и отрисовать всё по координатам: java-аплеты, activeX-компоненты, silverlight... Разумеется, они сработали, т.к. игнорировали особенности человеческого зрения. Сейчас продвигаются Blazor и Flutter. Слышал, что flutter уже столкнулся с проблемой мутного текста, какие-то решения этого в нем есть, но насколько они полноценны мне пока не понятно.
С одной стороны да, зачем писать велосипед, если можно использовать готовые реализации от браузера. А с другой, приходится чтобы чуть-чуть подправить какое-то поведение (например, у дефолтного фокуса для input по клику в его label), приходится городить костыли и периодически проще чуть ли не всё самому наваять, обмазав сверху role и aria-мусором. Или вместо очередного васяпакета/самописного уродца для выбора, к примеру, цвета, мы берём input[type="color]. И ловимся на том, что на каждой оси селектор разный, и если на каком-нибудь липуксе или макосе он ещё приемлемый, то виндовый - (ИМХО, конечно) это просто мерзко.
Ну и со стилизацией нативных селектов здравствуйте, спасибо хоть за столько лет возникла инициатива, не помню уже как она там точно называется, на создание нативного, но стилизуемого селекта.
И за accent-color спасибо, вот это тоже приятно было
Вот что еще любопытно. Есть такой язык post script (PS). Используется в принтерах и внутри pdf. Предназначен для отрисовки текста и графики. Язык вполне полноценный, хотя со своеобразным синтаксисом (обратная польская запись). По сути - это клон Форта.
PS появился лет на 10 раньше html. По функциональности, уже тогда, мог бы заменить html, js и svg. Если бы кто-то не нашел бы в то время в PS "фатальный недостаток", возможно, сейчас бы все фронт эндеры писали бы на форте, а бэкэндеры на каком-нибудь nodeps. 😁
Если бы кто-то не нашел бы в то время в PS "фатальный недостаток",
Фатальный недостаток PS в том что он проприетарный, а Адоб берет бабло за его использование
также HTML более дружелюбен, на нем можно писать вообще ничерта не понимая в программировании и этомвотвсём js/css... и чтото даже получится
а PS (глянул примеры кода) это крындец какойто, тогда уж сразу на техе писать надо
Главная проблема PS это то что он полный по Тюнингу.
Соответственно вам можно любой вирусные в виде ps страницы закинуть.
Хотя с JavaScript такая же фигня вышла :)
Полнота по Тьюрингу - это математическое понятие, не более того. Связку HTML+CSS тоже можно считать тьюринг-полной.
Еще ведь есть TeX, который тоже язык разметки и появился на 15 лет раньше html. Я его не знаю, но пару раз сталкивался (кажется на форуме dxdy), и этого оказалось достаточно чтобы понять - хорошая штука, для формул точно лучше чем громоздкий MathML.
PS - процедурный язык, а HTML - декларативный. Но у HTML главное текст, поэтому корректнее было бы привести здесь SVG.
Спасибо, не надо. Если что, я писал на PS. И я бы сказал, что это два совершенно разных по назначению языка. Это не значит, что PS плохой, вовсе нет. Но далеко не факт, что для той задачи, что мы сегодня имеем, он был бы лучше.
Фатальный недостаток PS в том, что он кодирует полоски текста (и других примитивов), прибитые к координатам, ни о каком layout manager там речи не идёт. Поэтому, кстати, PDF (как наследник PS) так отвратительно читается на смартфонах — он не умеет нормально масштабироваться при изменении пропорций.
На самом деле возврат к основам HTML, простым сайтам и читаемому коду без сложных фреймворков — довольно популярная идея.
Хочется верить.
А ещё голый HTML, сформированные с некоторыми правилами, парсится как валидный XML-документ (и наоборот). Шутка звалась data islands, как я помню. В своё время у одного проекта пожелания заказчика были весьма специфичными - и мой код собирал таких "XML-оборотней", которые корректно открывались браузером.
Что могут PWA
Вау, сколько возможностей открывается для разработчиков.
Не подскажите, как эту шнягу отключить надёжно и навсегда?
все логично.
чистый хтмл это признак здорового мышления разработчика. потому что: фреймворки и другая нечисть выпускается если не каждый день новый то несколько. потому что: код должен быть чистым и прозрачным. потому что: главное на сайте это содержимое, а не шаблон.
сколько уже было перемен в веб разработке, то многоколоночные сайты, то горизонтальные (начало-середина 00х), флеш и другая нечисть (когда он был еще макромедиа - можно было мериться, работал на первопнях и не глючила страница при 16мб озу), потом все перешли на фреймворки, а это жуть та еще, обновлять костыль каждый год-два. понаделали нескучных (как оказалось скучнейших) лендингов в последние 10 лет, как оказалось - дизайн везде типичен - скроллеры изображений которые переворачивают картинку (про пользователя никто не подумал, на каждое изображение нужно разное колличество времени переварить информацию), иконки размером с кулак, и типичная для всех информация "мы молодая но опытная команда". я даже скажу пару плохих слов про адаптивность и бутстрап (будь он неладен).
если вы делаете страницу которая предназначена для десктопа - не мучайте людей с телефонами, они вполне могут свайпнуть двумя пальцами где надо расширить где надо сузить. если же сайт расчитан на пользователей телефонов - вопросов нет, врятли кто-то со стационарника обидется если у него на экране будет портянка с информацией, ведь главное это информация.
всем не угодишь. поисковики вас запомнят не потому что у вас верстка адаптивная под каждую цацку, а потому что у вас ценная инфа на сайте.
Костыли из 90-х и принцип HTML First