Мы можем насмехаться над Баллмером за этот полубезумный нервный срыв, но его месседж попал в цель. Если не дать разработчикам инструменты и знания, которые необходимы для работы с вашей системой, они не только будут испытывать трудности, но и не смогут развивать то, над чем вы работаете!
Увы, на практике мы видим, что в этом отношении сами разработчики могут быть своими худшими врагами. Они выбирают ужасные «фреймворки», заставляющие их трудиться больше, а не продуманней, или намеренно бравируют своим незнанием фундаментальных основ и копируют чужой код в надежде, что он выполнит нужную задачу.
Ни в одной области это так не очевидно, как в высокомерном, пофигистском, а то и откровенно презрительном отношении к HTML. Нет пределов для бесконечных благоглупостей и ошибочных заявлений от тех, кто не способен написать ни одной строки на этом языке.
Если в двух словах, разработчики воспринимают HTML недостаточно серьёзно, но что произойдёт, если вы укажете им на их слабость? В ответ мы дождёмся только бесконечный поток бессмысленных оправданий того, почему их нельзя отвлекать на его правильную реализацию!
Это последовательность команд, которым следуют компьютеры для выполнения задачи. Если и есть другое определение языка программирования, то за четыре десятка лет написания ПО я его не слышал. Является ли от Тьюринг-полным? Нет… но тем не менее он сообщает компьютеру, как передать грамматическое и структурное значение контента в машинонезависимом виде. Есть правила по использованию его тэгов, порядка и синтаксиса.
Ровно до того момента, как вы не столкнётесь с незрячими пользователями. HTML — это не только то, как выглядит страница… Нет! Исправлюсь — HTML вообще не о том, как что-то выглядит. HTML нужен для того, что сообщить, какими должны быть элементы с точки зрения грамматики и структуры, чтобы user-agent мог передать это значение пользователю. Поэтому для описания того, как должны выглядеть элементы, у нас есть CSS. Если любой из ваших тэгов, id или классов сообщает о том, как элементы должны выглядеть, то вы выбрали неподходящий код, исходя из неверных предпосылок.
Скринридеры (ПО для чтения страницы вслух), электронные книги со шрифтом Брайля, TTY… всё это невизуальные целевые объекты; и не забывайте, что у поисковых движков тоже нет глаз. Им нет ни малейшей разницы, как «выглядит» ваша страница.
Кроме того, людям важно, что ваша страница медленнее или её хостинг обходится дороже, или она нарушает правила доступности для людей с ограничениями, или она забивает весь доступный канал. Несемантическая разметка, бесконечные и бессмысленные DIV, не делающие ничего, presentational classes — все они складываются и влияют на результат!
Вы будете слышать те же оправдания для множества других аспектов веб-разработки, и почти всегда это ложь. Будь то плохая/поломанная семантика, проблемы с доступностью для людей с ограничениями, раздутый необязательный JS, использование технологий «веб-приложений» для того, что приложением быть не должно, и т.д., и т.п.
Очень часто при использовании всего этого пользователь понимает, что что-то не так, но не может этого объяснить. Пользователи не программисты, они не знают, в чём ошибка и кто в ней виноват, но они ощущают, что что-то не так, всё вкривь и вкось.
А как насчёт следующего несчастного неудачника, которому придётся поддерживать результат вашего труда, в котором собраны все ошибки из списка, как НЕ нужно использовать HTML? Люди всегда болтают о том, как их ужасный поломанный «фреймворк» должен «помогать в совместной работе». Как в два или десять раз больший объём кода, не соответствующий базовым правилам HTML и нарушающий само предназначение этого языка, может «улучшить совместную работу»?
Они не специалисты в веб-разработке. Скорее, специалисты в маркетинге, пропаганде и обмане. Разметка в примерах таких систем, как Bootstrap и Tailwind — это кошмарные практики HTML. Они воняют ужасной смесью заявлений «я не хочу изучать HTML и CSS» и «я скучаю по разметке 1990-х», отказываясь от двадцати с лишним лет прогресса. Только потому, что их используют миллионы сайтов («большинство не может ошибаться»), а самозванные эксперты поют им хвалебные оды (апелляция к авторитету), не делает их или подобные практики хорошими.
Сложным делаете его вы. В том-то и проблема: игнорируя семантические правила структурирования и весь смысл предназначения HTML, вы усложняете работу с ним. Способствует этому и то, что приманки для нубов наподобие W3Schools (aka W3fools) переполнены неточной информацией, вульгарными упрощениями и полным отсутствием большинства из базовых концепций HTML.
Контент должен определять разметку, контент + разметка + целевая среда/возможности user-agent должны определять структуру. Следуя базовой семантике и благодаря постепенному совершенствованию и использованию правильного разделения функциональности, вы в конечном итоге получите набор инструкций, позволяющий с лёгкостью создавать простые в поддержке страницы. Если у вас возникают с этим проблемы и вы считаете, что эти «фреймворки HTML/CSS» упрощают вашу жизнь, значит, вы недостаточно хорошо знаете HTML или CSS для выполнения хоть каких-то задач.
Вообще, Tailwind проще, чем ванильные HTML/CSS, достаточно просто выучить более 500 классов, 90% из которых уже существуют в виде свойств CSS, а затем игнорировать почти все правила того, как должен использоваться HTML!
Если вы не поняли, это был сарказм.
Я постоянно слышу эту чушь, и меня раздражает её недальновидность!
Это как говорить, что я уделяю слишком много внимания почве под стройплощадкой или материалам, используемым для создания фундамента. Если вы пренебрегаете такими деталями, то не удивляйтесь, что потом всё «непонятным образом» обвалится или будет затянуто в карстовую воронку!
HTML — это фундамент и краеугольный камень. Если им пренебречь, то не удивляйтесь, что результаты будут полной катастрофой.
И в самом деле, многие заблуждения, которыми веб-разработчики убеждают себя не беспокоиться о будущем, не отличаются от тех, которые приводят ко всем инженерным катастрофам. Экономия на качестве, игнорирование спецификаций или конечного пользователя, подпитывание собственного эго; к тому же многие совершают фатальную ошибку — путают искусство с проектированием.
Последняя ошибка приводит к возникновению зданий, ослепляющих людей отражённым их окнами солнечным светом: некто, возомнивший себя художником, убеждает людей в костюмах потратить миллиарды на проект, в котором форма важнее функции.
Это оправдание имеет множество разных версий, но в целом они подразумевают написанное выше. Говорящие это почти всегда относятся к поклонникам «веб-приложений» или «одностраничных приложений», они пытаются использовать JavaScript везде, они не заботятся о доступности для людей с ограничениями и настаивают, что «пользователям» почему-то «нужны» все их модные причиндалы для улучшения «user experience».
Но если быть предельно честным, эти клоуны знают об UX столько же, сколько знают о дизайне художники, впавшие в иллюзию того, что они являются «веб-дизайнерами».
И результаты их работы вы УЖЕ СЕЙЧАС видите во всей нашей отрасли: хрупкие, распухшие, медленные решения, которые «способен улучшить скриптинг», настолько затормаживают системы корзин интернет-магазинов, что многие из них даже неспособны поддерживать аптайм (привет, Zotac); при этом пользователи ожесточённо жмут на F5, надеясь, что им всё-таки удастся купить видеокарту. Из-за перезагрузки всей страницы целиком и повторного запуска скрипта все функции «приложения» приводят только к УМЕНЬШЕНИЮ скорости загрузки страницы. И ещё сильнее это проявляется, если вы плюёте на разметку, пользуясь presentational classes.
А поскольку скрипты можно отключать, и генерируемый скриптами контент сложнее для скринридеров, электронных книг со шрифтом Брайля, и так далее, одностраничные приложения (single-page application, SPA) нарушают правила доступности для людей с ограничениями.
Я не говорю, что SPA и им подобные не имеют разумных способов применения, но если вы не можете создать простую корзину или банковский портал с быстрой загрузкой, который мало теряет от отключения скриптов, то вам, вероятно, не стоит заниматься работой на какой бы то ни было бизнес. Веб-приложения НЕ должны использоваться для чего-то столь смехотворно простого, как корзина на веб-сайте!
И если вы думаете, что использование скриптинга для этого действительно улучшает user experience, то вы, очевидно, не тестировали систему на реальных пользователях и реальном трафике! По крайней мере, не выполняли реального сравнения разделения задач с использованием кэша в загрузках нормальных страниц и на страницах с новомодными скриптами.
Ни в коем случае. Вернёмся к началу статьи и к крикам Баллмера «разработчики, разработчики, разработчики».
Когда он разыгрывал свою небольшую сценку, она была призвана решить проблему того, что в конце 90-х Windows ни в коем случае не была на первом месте, потому что разработчики часто не использовали предоставляемые компанией Microsoft инструменты. Лучшую документацию по Windows API напечатала Borland. Люди использовали инструменты не от Microsoft, потому что «визуальные» языки считались игрушками. Они так сильно отставали от технологий веб-разработки, то можно сказать, что они и сейчас пытаются их догнать!
У W3C и WhatWG есть похожие проблемы с тем что так называемые «спецификации» попросту написаны не для людей, которые пишут веб-сайты. Позвольте мне повторить: спецификация языка, используемого для написания веб-сайтов, предназначена не для людей, которые на самом деле пишут веб-сайты. Она написана для людей, которые пишут user-agents! Браузер — это user-agent, но UA — не всегда браузер.
На самом деле, это такой абсурд, что идиотическая версия «динамичного документа» WhatWG ссылается на MDN, чтобы её могли понять «простые смертные».
Примечание: я даже не буду начинать рассуждения о том, насколько тупой является сама идея «динамичного документа» (living document), особенно потому что в реальных HTML-документах отсутствует отслеживание версий. HTML 5, который был валиден в прошлом году, становится сегодня невалидным HTML 5, а сегодняшний валидный HTML 5 может стать невалидным завтра? Отличный способ сделать валидацию совершенно бесполезной!
Простой факт: для получения описаний значений тэгов на простом английском приходится обращаться к сторонним источникам, многие из которых даже не согласуются друг с другом. Более того, W3C стала совершенно беззубой, она слепо соглашается со всем, что говорит WhatWG, даже несмотря на то, что WhatWG многократно доказала, что она не имеет достаточной квалификации для создания потомка HTML 4 Strict. Принятие EMBED в качестве валидного тэга, создание и/или поддержка тэгов, избыточных относительно OBJECT, больше не поддерживаемый (к счастью) тэг HGROUP, показавший, что они даже не понимают, для чего нужны нумерованные заголовки и как их использовать… По признанию многих, кто над ним работал, задача HTML 5 на самом деле никогда не заключалась в создании спецификации или стандарта, говорящего нам, как создавать полезные веб-сайты! Она заключалась в документировании того, делают ли сегодня люди правильно или неправильно, и того, что браузеры могут поддерживать, но не того, что они должны поддерживать! Учитывая то, что во время разработки HTML 5 большинство разработчиков всё ещё вбивало HTML 3.2 и набрасывало поверх него извращённый doctype HTML 4, к чему удивляться, что всё оказалось таким скоплением плохих, устаревших и старомодных практик?
Если уж разработчики не воспринимают HTML достаточно серьёзно, то обвинять в этом стоит тех, кто разрабатывал его как «спецификацию»; даже назвать подобное именем HTML 5 было таким серьёзным преступлением против веб-разработки… Как преступлением против музыки стало вручение «Грэмми» Билли Эйлиш за её бесталанные творения.
W3C и WhatWG даже не воспринимаются серьёзно другими организациями по стандартизации, и на то есть причина.
Неплохо бы для начала добиться от разработчиков, чтобы они не воспринимали HTML как недоразвитого ребёнка от мира языков программирования. В частности, заставить их практиковать семантическую разметку с разделением представления от контента, что сильно повысит юзабилити, доступность и эффективность.
Кроме того, мы сами как разработчики должны сказать своё слово и озадачить W3C за то, что её работа в качестве органа сертификации катастрофически провалилась. Нам нужно потребовать более простую и чистую документацию языка от официального источника. Никак нельзя оправдать то, что документ, описывающий столь простую вещь, как HTML, в пять-десять раз длиннее конституций большинства развитых стран. Само то, что спецификация языка, используемого для создания веб-сайтов, написана не для людей, которые используют язык для создания веб-сайтов, является вотумом недоверия.
Но нам нужна не просто улучшенная официальная документация, необходимо урезать язык, сделать его более ориентированным на задачи. Возродить многие идеи, которые содержались в HTML 5 до того, как W3C выкинула их на помойку и приняла версию WhatWG. Тот факт, что Microsoft потратила десятки лет на то, чтобы IE препятствовал нам использовать OBJECT — ещё не причина не только сохранять тэг IMG, но и добавлять множество новых тэгов без нужды (VIDEO, AUDIO). Просто потому, что «художники» и жулики от маркетинга любят открывать для пользователя новые окна, нравится ему это или нет, ещё не причина того, чтобы в спецификации было TARGET="_BLANK".
Более того, ЯВНОЕ использование и значения тэгов необходимо поместить в центр спецификации, а может быть, даже в отдельное руководство по использованию для тех, кто по-прежнему живёт в 1997 году.
Создание более простой, чистой и полезной версии HTML, которая станет руководством для нас всех — не такая уж сложная задача.
Кроме того, нам полезно будет, если при её создании меньший вес будут иметь разработчики браузеров. Microsoft, Mozilla, Apple и Google имеют огромное влияние на W3C и WhatWG, и это совершенно неэтично. Их вес в процессе принятия решений противоречит самой концепции свободного и открытого веба.
Источник статьи: https://habr.com/ru/company/vdsina/blog/559482/
Увы, на практике мы видим, что в этом отношении сами разработчики могут быть своими худшими врагами. Они выбирают ужасные «фреймворки», заставляющие их трудиться больше, а не продуманней, или намеренно бравируют своим незнанием фундаментальных основ и копируют чужой код в надежде, что он выполнит нужную задачу.
Ни в одной области это так не очевидно, как в высокомерном, пофигистском, а то и откровенно презрительном отношении к HTML. Нет пределов для бесконечных благоглупостей и ошибочных заявлений от тех, кто не способен написать ни одной строки на этом языке.
Если в двух словах, разработчики воспринимают HTML недостаточно серьёзно, но что произойдёт, если вы укажете им на их слабость? В ответ мы дождёмся только бесконечный поток бессмысленных оправданий того, почему их нельзя отвлекать на его правильную реализацию!
Список слабых оправданий
Это последовательность команд, которым следуют компьютеры для выполнения задачи. Если и есть другое определение языка программирования, то за четыре десятка лет написания ПО я его не слышал. Является ли от Тьюринг-полным? Нет… но тем не менее он сообщает компьютеру, как передать грамматическое и структурное значение контента в машинонезависимом виде. Есть правила по использованию его тэгов, порядка и синтаксиса.
Ровно до того момента, как вы не столкнётесь с незрячими пользователями. HTML — это не только то, как выглядит страница… Нет! Исправлюсь — HTML вообще не о том, как что-то выглядит. HTML нужен для того, что сообщить, какими должны быть элементы с точки зрения грамматики и структуры, чтобы user-agent мог передать это значение пользователю. Поэтому для описания того, как должны выглядеть элементы, у нас есть CSS. Если любой из ваших тэгов, id или классов сообщает о том, как элементы должны выглядеть, то вы выбрали неподходящий код, исходя из неверных предпосылок.
Скринридеры (ПО для чтения страницы вслух), электронные книги со шрифтом Брайля, TTY… всё это невизуальные целевые объекты; и не забывайте, что у поисковых движков тоже нет глаз. Им нет ни малейшей разницы, как «выглядит» ваша страница.
Кроме того, людям важно, что ваша страница медленнее или её хостинг обходится дороже, или она нарушает правила доступности для людей с ограничениями, или она забивает весь доступный канал. Несемантическая разметка, бесконечные и бессмысленные DIV, не делающие ничего, presentational classes — все они складываются и влияют на результат!
Вы будете слышать те же оправдания для множества других аспектов веб-разработки, и почти всегда это ложь. Будь то плохая/поломанная семантика, проблемы с доступностью для людей с ограничениями, раздутый необязательный JS, использование технологий «веб-приложений» для того, что приложением быть не должно, и т.д., и т.п.
Очень часто при использовании всего этого пользователь понимает, что что-то не так, но не может этого объяснить. Пользователи не программисты, они не знают, в чём ошибка и кто в ней виноват, но они ощущают, что что-то не так, всё вкривь и вкось.
А как насчёт следующего несчастного неудачника, которому придётся поддерживать результат вашего труда, в котором собраны все ошибки из списка, как НЕ нужно использовать HTML? Люди всегда болтают о том, как их ужасный поломанный «фреймворк» должен «помогать в совместной работе». Как в два или десять раз больший объём кода, не соответствующий базовым правилам HTML и нарушающий само предназначение этого языка, может «улучшить совместную работу»?
Они не специалисты в веб-разработке. Скорее, специалисты в маркетинге, пропаганде и обмане. Разметка в примерах таких систем, как Bootstrap и Tailwind — это кошмарные практики HTML. Они воняют ужасной смесью заявлений «я не хочу изучать HTML и CSS» и «я скучаю по разметке 1990-х», отказываясь от двадцати с лишним лет прогресса. Только потому, что их используют миллионы сайтов («большинство не может ошибаться»), а самозванные эксперты поют им хвалебные оды (апелляция к авторитету), не делает их или подобные практики хорошими.
Сложным делаете его вы. В том-то и проблема: игнорируя семантические правила структурирования и весь смысл предназначения HTML, вы усложняете работу с ним. Способствует этому и то, что приманки для нубов наподобие W3Schools (aka W3fools) переполнены неточной информацией, вульгарными упрощениями и полным отсутствием большинства из базовых концепций HTML.
Контент должен определять разметку, контент + разметка + целевая среда/возможности user-agent должны определять структуру. Следуя базовой семантике и благодаря постепенному совершенствованию и использованию правильного разделения функциональности, вы в конечном итоге получите набор инструкций, позволяющий с лёгкостью создавать простые в поддержке страницы. Если у вас возникают с этим проблемы и вы считаете, что эти «фреймворки HTML/CSS» упрощают вашу жизнь, значит, вы недостаточно хорошо знаете HTML или CSS для выполнения хоть каких-то задач.
Вообще, Tailwind проще, чем ванильные HTML/CSS, достаточно просто выучить более 500 классов, 90% из которых уже существуют в виде свойств CSS, а затем игнорировать почти все правила того, как должен использоваться HTML!
Если вы не поняли, это был сарказм.
Я постоянно слышу эту чушь, и меня раздражает её недальновидность!
Это как говорить, что я уделяю слишком много внимания почве под стройплощадкой или материалам, используемым для создания фундамента. Если вы пренебрегаете такими деталями, то не удивляйтесь, что потом всё «непонятным образом» обвалится или будет затянуто в карстовую воронку!
HTML — это фундамент и краеугольный камень. Если им пренебречь, то не удивляйтесь, что результаты будут полной катастрофой.
И в самом деле, многие заблуждения, которыми веб-разработчики убеждают себя не беспокоиться о будущем, не отличаются от тех, которые приводят ко всем инженерным катастрофам. Экономия на качестве, игнорирование спецификаций или конечного пользователя, подпитывание собственного эго; к тому же многие совершают фатальную ошибку — путают искусство с проектированием.
Последняя ошибка приводит к возникновению зданий, ослепляющих людей отражённым их окнами солнечным светом: некто, возомнивший себя художником, убеждает людей в костюмах потратить миллиарды на проект, в котором форма важнее функции.
Это оправдание имеет множество разных версий, но в целом они подразумевают написанное выше. Говорящие это почти всегда относятся к поклонникам «веб-приложений» или «одностраничных приложений», они пытаются использовать JavaScript везде, они не заботятся о доступности для людей с ограничениями и настаивают, что «пользователям» почему-то «нужны» все их модные причиндалы для улучшения «user experience».
Но если быть предельно честным, эти клоуны знают об UX столько же, сколько знают о дизайне художники, впавшие в иллюзию того, что они являются «веб-дизайнерами».
И результаты их работы вы УЖЕ СЕЙЧАС видите во всей нашей отрасли: хрупкие, распухшие, медленные решения, которые «способен улучшить скриптинг», настолько затормаживают системы корзин интернет-магазинов, что многие из них даже неспособны поддерживать аптайм (привет, Zotac); при этом пользователи ожесточённо жмут на F5, надеясь, что им всё-таки удастся купить видеокарту. Из-за перезагрузки всей страницы целиком и повторного запуска скрипта все функции «приложения» приводят только к УМЕНЬШЕНИЮ скорости загрузки страницы. И ещё сильнее это проявляется, если вы плюёте на разметку, пользуясь presentational classes.
А поскольку скрипты можно отключать, и генерируемый скриптами контент сложнее для скринридеров, электронных книг со шрифтом Брайля, и так далее, одностраничные приложения (single-page application, SPA) нарушают правила доступности для людей с ограничениями.
Я не говорю, что SPA и им подобные не имеют разумных способов применения, но если вы не можете создать простую корзину или банковский портал с быстрой загрузкой, который мало теряет от отключения скриптов, то вам, вероятно, не стоит заниматься работой на какой бы то ни было бизнес. Веб-приложения НЕ должны использоваться для чего-то столь смехотворно простого, как корзина на веб-сайте!
И если вы думаете, что использование скриптинга для этого действительно улучшает user experience, то вы, очевидно, не тестировали систему на реальных пользователях и реальном трафике! По крайней мере, не выполняли реального сравнения разделения задач с использованием кэша в загрузках нормальных страниц и на страницах с новомодными скриптами.
То есть во всём виноват веб-разработчик?
Ни в коем случае. Вернёмся к началу статьи и к крикам Баллмера «разработчики, разработчики, разработчики».
Когда он разыгрывал свою небольшую сценку, она была призвана решить проблему того, что в конце 90-х Windows ни в коем случае не была на первом месте, потому что разработчики часто не использовали предоставляемые компанией Microsoft инструменты. Лучшую документацию по Windows API напечатала Borland. Люди использовали инструменты не от Microsoft, потому что «визуальные» языки считались игрушками. Они так сильно отставали от технологий веб-разработки, то можно сказать, что они и сейчас пытаются их догнать!
У W3C и WhatWG есть похожие проблемы с тем что так называемые «спецификации» попросту написаны не для людей, которые пишут веб-сайты. Позвольте мне повторить: спецификация языка, используемого для написания веб-сайтов, предназначена не для людей, которые на самом деле пишут веб-сайты. Она написана для людей, которые пишут user-agents! Браузер — это user-agent, но UA — не всегда браузер.
На самом деле, это такой абсурд, что идиотическая версия «динамичного документа» WhatWG ссылается на MDN, чтобы её могли понять «простые смертные».
Примечание: я даже не буду начинать рассуждения о том, насколько тупой является сама идея «динамичного документа» (living document), особенно потому что в реальных HTML-документах отсутствует отслеживание версий. HTML 5, который был валиден в прошлом году, становится сегодня невалидным HTML 5, а сегодняшний валидный HTML 5 может стать невалидным завтра? Отличный способ сделать валидацию совершенно бесполезной!
Простой факт: для получения описаний значений тэгов на простом английском приходится обращаться к сторонним источникам, многие из которых даже не согласуются друг с другом. Более того, W3C стала совершенно беззубой, она слепо соглашается со всем, что говорит WhatWG, даже несмотря на то, что WhatWG многократно доказала, что она не имеет достаточной квалификации для создания потомка HTML 4 Strict. Принятие EMBED в качестве валидного тэга, создание и/или поддержка тэгов, избыточных относительно OBJECT, больше не поддерживаемый (к счастью) тэг HGROUP, показавший, что они даже не понимают, для чего нужны нумерованные заголовки и как их использовать… По признанию многих, кто над ним работал, задача HTML 5 на самом деле никогда не заключалась в создании спецификации или стандарта, говорящего нам, как создавать полезные веб-сайты! Она заключалась в документировании того, делают ли сегодня люди правильно или неправильно, и того, что браузеры могут поддерживать, но не того, что они должны поддерживать! Учитывая то, что во время разработки HTML 5 большинство разработчиков всё ещё вбивало HTML 3.2 и набрасывало поверх него извращённый doctype HTML 4, к чему удивляться, что всё оказалось таким скоплением плохих, устаревших и старомодных практик?
Если уж разработчики не воспринимают HTML достаточно серьёзно, то обвинять в этом стоит тех, кто разрабатывал его как «спецификацию»; даже назвать подобное именем HTML 5 было таким серьёзным преступлением против веб-разработки… Как преступлением против музыки стало вручение «Грэмми» Билли Эйлиш за её бесталанные творения.
W3C и WhatWG даже не воспринимаются серьёзно другими организациями по стандартизации, и на то есть причина.
Каким же должно быть решение?
Неплохо бы для начала добиться от разработчиков, чтобы они не воспринимали HTML как недоразвитого ребёнка от мира языков программирования. В частности, заставить их практиковать семантическую разметку с разделением представления от контента, что сильно повысит юзабилити, доступность и эффективность.
Кроме того, мы сами как разработчики должны сказать своё слово и озадачить W3C за то, что её работа в качестве органа сертификации катастрофически провалилась. Нам нужно потребовать более простую и чистую документацию языка от официального источника. Никак нельзя оправдать то, что документ, описывающий столь простую вещь, как HTML, в пять-десять раз длиннее конституций большинства развитых стран. Само то, что спецификация языка, используемого для создания веб-сайтов, написана не для людей, которые используют язык для создания веб-сайтов, является вотумом недоверия.
Но нам нужна не просто улучшенная официальная документация, необходимо урезать язык, сделать его более ориентированным на задачи. Возродить многие идеи, которые содержались в HTML 5 до того, как W3C выкинула их на помойку и приняла версию WhatWG. Тот факт, что Microsoft потратила десятки лет на то, чтобы IE препятствовал нам использовать OBJECT — ещё не причина не только сохранять тэг IMG, но и добавлять множество новых тэгов без нужды (VIDEO, AUDIO). Просто потому, что «художники» и жулики от маркетинга любят открывать для пользователя новые окна, нравится ему это или нет, ещё не причина того, чтобы в спецификации было TARGET="_BLANK".
Более того, ЯВНОЕ использование и значения тэгов необходимо поместить в центр спецификации, а может быть, даже в отдельное руководство по использованию для тех, кто по-прежнему живёт в 1997 году.
Создание более простой, чистой и полезной версии HTML, которая станет руководством для нас всех — не такая уж сложная задача.
Кроме того, нам полезно будет, если при её создании меньший вес будут иметь разработчики браузеров. Microsoft, Mozilla, Apple и Google имеют огромное влияние на W3C и WhatWG, и это совершенно неэтично. Их вес в процессе принятия решений противоречит самой концепции свободного и открытого веба.
Источник статьи: https://habr.com/ru/company/vdsina/blog/559482/