веб стандарты что это такое
Веб-стандарты
СОДЕРЖАНИЕ
Обзор [ править ]
Веб-стандарты состоят из следующего:
В более широком смысле, следующие технологии также могут называться «веб-стандартами»:
Движение веб-стандартов [ править ]
Обычное использование [ править ]
При обсуждении веб-стандартов следующие публикации обычно считаются основополагающими:
Работа W3C над Семантической паутиной в настоящее время сосредоточена на публикациях, связанных со структурой описания ресурсов (RDF), сбором описаний ресурсов из диалектов языков (GRDDL) и языком веб-онтологий (OWL).
Публикации и органы по стандартам [ править ]
Интернет-стандарт IETF характеризуется высокой степенью технической зрелости и общепринятым убеждением, что указанный протокол или услуга приносит значительную пользу Интернет-сообществу. Спецификации, которая достигает статуса Standard, присваивается номер в серии IETF STD с сохранением исходного номера IETF RFC.
Нестандартные и проприетарные давления производителей [ править ]
HTML 5 содержит многочисленные «умышленные нарушения» других спецификаций, чтобы учесть ограничения существующих платформ. [18]
Тестирование на соответствие веб-стандартам [ править ]
Существуют тесты на соответствие как для HTML-кода, генерируемого веб-сайтами, так и для точной интерпретации HTML-кода веб-браузерами.
Тесты на соответствие кода веб-сайта [ править ]
W3C предлагает онлайн-услуги для тестирования веб-сайтов напрямую как для разработчиков веб-сайтов, так и для пользователей веб-сайтов. Это включает:
Тесты на соответствие для веб-браузеров [ править ]
веб-стандарты
Веб-стандарты делают веб-разработки проще.
Веб-стандарты, разработанные консорциумом World Wide Web (W3C).
Почему веб-стандарты?
Для разработчиков браузеров и разработчиков веб-приложений, чтобы соответствовать установленным стандартам в разработке новых приложений в большей степени способствует лучшему развитию веб.
Веб-разработчик в соответствии со стандартными веб-страниц, так и для разработчиков еще проще, потому что они могут легко понять кодирование друг друга
Использование веб-стандартов, будет гарантировать, что все браузеры корректно отображаться на вашем сайте без трудоемкого переписывания.
Соответствуют стандартной веб-страницы может облегчить доступ к страницам поисковой системы и доходы, чтобы быть более легко преобразованы в другие форматы, а также более доступными программный код (например, JavaScript и DOM).
доступной
Доступность является важной частью стандарта HTML.
Веб-стандарты делают его более легким для людей с ограниченными возможностями использовать Интернет.
Веб-стандарты, чтобы люди с ограниченными возможностями могут легко пользоваться Интернетом. Слепые люди могут использовать программа считывает веб-страницы для них. В незрячие перестановкой страницу и увеличить, чтобы получить доступ к сайту.
W3C для создания и поддержания веб-стандартов.
Тим Бернерс-Ли (Tim Berners-Lee) является отцом основателем консорциума World Wide Web известен как изобретатель Интернета:
Консорциум World Wide Web, созданная в 1994 году, является международной ассоциацией, целью которой является участие в «вести в Интернете, чтобы стимулировать их полный потенциал.»
Наиболее важные стандарты W3C:
ECMA в 1960 году в Брюсселе, основанный некоторыми из крупнейших европейских компьютерных и технологических компаний. В мае 1961 года они создали формальную организацию, цель этой организации заключается в оценке, разработке и распознавания телекоммуникационных и компьютерных стандартов.
Мы решили ECMA базируется в Женеве, так как это может сделать настройки организации ближе к какой-то другой стандарт, с которым работать, скажем, Международная организация по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).
Последняя спецификация ECMAScript является ECMA- 262:
Веб-стандарты
СОДЕРЖАНИЕ
Обзор [ править ]
Веб-стандарты состоят из следующего:
В более широком смысле, следующие технологии также могут называться «веб-стандартами»:
Движение веб-стандартов [ править ]
Обычное использование [ править ]
При обсуждении веб-стандартов следующие публикации обычно считаются основополагающими:
Работа W3C над Семантической паутиной в настоящее время сосредоточена на публикациях, связанных со структурой описания ресурсов (RDF), сбором описаний ресурсов из диалектов языков (GRDDL) и языком веб-онтологий (OWL).
Публикации и органы по стандартам [ править ]
Интернет-стандарт IETF характеризуется высокой степенью технической зрелости и общепринятым убеждением, что указанный протокол или услуга приносит значительную пользу Интернет-сообществу. Спецификации, которая достигает статуса Standard, присваивается номер в серии IETF STD с сохранением исходного номера IETF RFC.
Нестандартные и проприетарные давления производителей [ править ]
HTML 5 содержит многочисленные «умышленные нарушения» других спецификаций, чтобы учесть ограничения существующих платформ. [18]
Тестирование на соответствие веб-стандартам [ править ]
Существуют тесты на соответствие как для HTML-кода, сгенерированного веб-сайтами, так и для точной интерпретации HTML-кода веб-браузерами.
Тесты на соответствие кода веб-сайта [ править ]
W3C предлагает онлайн-услуги для тестирования веб-сайтов напрямую как разработчикам веб-сайтов, так и пользователям веб-сайтов. Они включают:
Тесты на соответствие для веб-браузеров [ править ]
Веб-компоненты и открытые стандарты
Если спросить разработчиков, почему они выбрали веб-компоненты для своего проекта, довольно часто можно услышать такие аргументы
Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.
Открытый стандарт
Открытость стандарта подразумевает то, что он написан с привлечением разных заинтересованных сторон. В результате получается удовлетворяющий всех результат. Что же произошло в этом случае? Открываем документ и видим его авторов
Все они работают в Гугле. Аналогичная ситуация и в истории коммитов в этот репозиторий. Попробуйте на графике контрибьюторов найти человека не из Гугла. В первой пятерке таких точно нет.
Получается, что этот стандарт написан почти на 100% в Гугле. Но, может быть, у сообщества была возможность высказать свои пожелания и они были услышаны? Давайте рассмотрим несколько примеров.
Глобальный реестр компонентов
Избегание глобальных сущностей является одним из важных аспектов дизайна масштабируемых систем. На эти грабли веб-разработка уже наступала в CSS, где любой класс применяется глобально ко всей странице. Веб-компоненты попытались починить это через Shadow DOM, но тут же сломали в другом месте, добавив глобальный реестр компонентов. Каждый компонент должен иметь уникальное имя, а если встретится дубликат, то выбросится исключение, и весь Javascript перестанет работать, если его не завернуть в try/catch.
Эту проблему зарепортил пользователь, но один из авторов стандарта ответил что проблемы никакой нет и закрыл тикет.
Спустя какое то время о той же самой проблеме сообщил уже сотрудник гугла, и этот тикет до сих пор висит открытым. Ну хоть к своим собственным разработчикам прислушиваются, уже неплохо.
Таким образом, спустя 6 лет после первоначальной публикации стандарта, мы все еще имеем проблему, которая должна была бы выявиться еще на первоначальном ревью. Хотя какое тут ревью, сотрудникам Гугла виднее, как именно нам будет хорошо.
Расширение нативных элементов
Возможно, Гугл игнорирует пожелания рядовых разработчиков, но прислушивается к разработчикам других браузерных движков? Они же все на общее дело работают. Но здесь тоже не все гладко.
Веб-компоненты предусматривают возможность расширения нативных элементов. Например, вы можете навесить дополнительную функциональность на тэг при помощи такого кода:
Этот код работает во всех современных браузерах, но не в Safari. Вот заявление разработчика webkit что они считают эту фичу хаком, вредящим будущему веба, и отказываются его поддерживать. В качестве альтернативы они выступают за поддержку custom-attributes по аналогии с custom-elements, но до стандарта этому предложению еще далеко.
Firefox тоже упоминает эту фичу в своем обзоре веб-компонентов (секция is=”” ) и показывает что у этой фичи больше минусов, чем плюсов
Тем не менее этот синтаксис все-таки попал в финальный стандарт, хоть не работает и никогда не будет в одном из трех основных браузеров, и тем самым опровергает правило «то что есть в стандарте, будет поддержано браузерами, рано или поздно»
Стабильность стандартов
В идеальном мире стандарты отличаются стабильностью, фичи не попадают в них просто так. Только проверенные временем практики оказываются в стандарте и крайне редко из него убираются.
В веб-компонентах все снова пошло не по плану. Изначально в пакет стандартов веб-компонентов входили еще и HTML-импорты. Предполагалось, что веб-компоненты будут импортироваться на страницу при помощи этой фичи.
Однако разработчики Firefox выступили против этой фичи. По их мнению, в это время уже были на подходе Javascript-модули и ещё один лишний механизм импорта в стандартах ни к чему.
В результате фича так и не дошла до финального стандарта, но ее реализация уже была добавлена в Chrome, и Google уже выпустил фреймворк Polymer, который на этот потенциальный стандарт опирался. В результате создатели Polymer были вынуждены переписать свой фреймворк без использования HTML-импортов, а пользователям этого фреймворка пришлось столкнуться с уникальным событием – необходимостью съезжать с устаревшего веб-стандарта.
Здесь еще можно вспомнить значительное переписывание стандарта Shadow DOM, когда внезапно оказалось, что написанная Гуглом версия стандарта не устраивает остальных вендоров.
Таким образом, и принцип «стандарт – гарант стабильности» с веб-компонентами не сработал.
Однако, в конечном итоге, веб-компоненты все-таки оказались стандартизованы. Казалось бы, теперь уже все устаканилось, можно наконец наслаждаться благами стабильных стандартов, но не тут-то было.
Псевдо-стандарты
К сожалению, Гугл так и не вынес ничего полезного из урока переписывания ранних стандартов Shadow DOM v0 и наступает на те же грабли еще раз.
Закономерным образом, при обсуждении этой спецификации с сообществом, вылезли недостатки дизайна. Но гуглеры не сдаются и призывают оставить поведение как есть, мотивируя это тем, что пользователи уже пользуются фичей в продакшене. В итоге получается такая ситуация:
Это не было бы так плохо, будь это единичный случай, но у Гугла есть целая организация с подобными псевдо-стандартами на Github: https://github.com/wicg. Неопытные пользователи могут подумать, что это еще одна организация наподобие WHATWG или W3C, но нет, WICG это такой своеобразный клуб по интересам:
Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Эта группа управляется сообществом. Несмотря на то что эти дискуссии проходят в рамках W3C, они не обязательно представляют взгляды членов W3C.
Таким образом, если вы видите очередной анонс нового «стандарта» от Гугла, советую проверять, откуда он исходит, и был ли там фидбек от других разработчиков браузеров.
Гугл оказывает очень большое давление на стандарты и вносит туда много разных фич. Не все браузеры способны поспевать за этим темпом и выбывают из борьбы. Сначала сошла с дистанции Opera и перешла на Chromium, теперь Edge. Эта ситуация развязывает руки Гуглу и позволяет добавлять в браузеры фичи, не советуясь ни с кем. В результате мы видим красивую картинку на caniuse, где 3 из 6 браузеров поддерживают некоторую фичу, в то время как Mozilla отмечает ее как вредную, поскольку она открывает возможность утечки данных пользователей.
Выводы
Надеюсь, эта статья позволит принять вам информированное решение об использовании веб-технологий. Статья выражает исключительно мое личное мнение, но содержит достаточно ссылок на источники, чтобы каждый смог их прочесть и составить своё собственное.
Если после всего этого вы все еще считаете веб-компоненты хорошим решением для вашего проекта, это замечательно. Но если единственным аргументом «за» был «ну это же веб-стандарт, они не могут ошибаться», то лучше пересмотреть свои выводы и перестать кушать этот кактус.
В погоне за веб стандартами
Мы уже рассказывали с какими проблемами мы сталкиваемся занимаясь фронтенд разработкой в 2018 году. Давайте посмотрим как далеко мы уходим от стандартов когда пишем наш код
и как мы можем решить эту проблему.
Современные браузеры умеют многое, они понимают ES6, поддерживают ES модули, предоставляют удобные средства для разработки и отладки. Но достаточно ли этого и пользуемся ли мы всеми этими средствами эффективно?
Давайте выделим основные отличия между нашим исходным кодом и кодом который мы загружаем в наш браузер:
Код доставляется одним файлом — хотя все современные браузеры понимают формат ES модулей, большинство инструментов для разработки склеивает наш код в один большой файл.
Новые возможности javascript — согласно таблице совместимости только последние десктопные версии chrome поддерживают 100% новых свойств языка (и лишь часть экспериментальных свойств), другие браузеры нуждаются в транспиляции и полифилах для отсутствующих свойств.
Новые возможности css — cssdb содержит список поддерживаемых современными браузерами свойств css, остальные должны быть скомпилированы.
Commonjs модули — родной для node.js формат модулей не смотря на свою популярность и распространенность не поддерживается ни одним браузером и должен быть преобразован (ES модули поддерживаются новыми версиями node.js в экспериментальном режиме, большинство библиотек по прежнему поставляются в Commonjs формате).
Простой импорт — (импорт начинающийся с имени пакета), браузерами не поддерживается, ведуться работы над черновиком стандарта (альтернативно уже сейчас можно консолидировать импорт в node.js и браузеры используя ES модули и переопределяя node.js загрузчик модулей для работы с абсолютными путями вида /node_modules/lodash/lib/get.js, но большинство библиотек этого не делает).
Импорт встроенных модулей — в браузерах также не поддерживается, требует замещение библиотеками.
Деструктуризация импорта — мы привыкли импортировать что угодно откуда угодно не заботясь о том, экспортируется ли требуемое нами значение:
на самом деле библиотека экспортирует один объект React, который содержит свойство Component, а не набор свойств как можно было подумать.
Импорт сторонних форматов (css, json и т.д.) — браузерами не поддерживается и судя по всему не будет (за исключением импорта wasm).
Декларации типов — typescript и flow стали очень популярны и помогают в разработке больших библиотек, но не имеют поддержки в браузерах.
Метаязыки — scss, sass, less, typescript, coffeescript, pug не являются стандартными и требуют компиляции.
Шаблоны jsx — не являются стандартом и должны быть преобразованы используя createElement:
Шаблоны vue — хотя и черпали вдохновение у веб компонентов, также не являются стандартом:
Относительные пути в веб компонентах — если вы привыкли разбивать ваши компоненты на скрипты шаблоны и стили, то вы знаете, что пути привязываются к корню проекта и компонент становится невозможно переносить и сложно переиспользовать в других проектах.
Если вы работаете с Angular:
Инъекция зависимостей — реализуется с помощью отражений и метаданных декораторов, требует компиляции.
Динамическая загрузка стилей по http — фреймворк не поддерживает эту возможность из коробки.
Как видим веб к которому мы привыкли далек от стандарта, хотя частично к нему и стремится. Задача hq сгладить эту разницу до тех пор пока многие вещи не войдут в стандарт, а другие не выйдут из обихода. hq это такой умный сервер, который делает ваш код чуть понятнее браузеру при этом преобразовывая только необходимый минимум и не склеивая все в одну кучу. Таким образом вне зависимости от выбранной технологии и фреймворка hq делает всю эту рутинную работу по обеспечению совместимости за вас и позволяет мгновенно приступить к разработке.
Какие еще преимущества дает hq?