Джереми Кейт – веб-разработчик, писатель и музыкант. Он является автором популярного блога и написал несколько книг, включая DOM Scripting, руководство по веб-дизайну с JavaScript и объектной модели документа.

История человеческой цивилизации – это история совокупных усилий. Каждое поколение опирается на работу своих предков.  Иногда работа делает шаг назад. Но мы продолжаем бороться. Шаг за шагом наш вид прогрессирует. Будь то постепенный прогресс или огромный скачок вперед, он всегда основывается на достижениях тех, кто был до нас.

Нигде этот многоуровневый характер прогресса не проявляется так ярко, как в истории технологии. Даже самые резкие скачки в технологическом прогрессе возможны только тогда, когда есть некий фундамент, на который можно опираться.

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

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

Стрелки на циферблате часов движутся по часовой стрелке только потому, что именно в этом направлении движется тень от солнечных часов в течение дня в северном полушарии. Если бы история повернулась иначе, и цивилизация южного полушария оказалась на подъеме, то стрелки на наших часах сегодня двигались бы в противоположном направлении. Что касается того, почему эти часы отмеряют время 24-часовыми периодами, каждый из которых состоит из 60 минут, а каждая минута – из 60 секунд, то это заслуга древней шумерской цивилизации.  Они решили использовать число 60 в качестве основы для счета и торговли. Это наименьшее число, которое может быть поровну разделено на первые шесть чисел. Этот шестидесятеричный способ счета сохранился до наших дней в виде часов, минут и секунд, которые мы используем в качестве концептуальных моделей для деления одного оборота нашей планеты.

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

Когда знания передаются из поколения в поколение, теории становятся более совершенными, единицы измерения стандартизируются, а точность экспериментов возрастает.

Сейчас самые точные эксперименты человечества проводятся под границей между Швейцарией и Францией.  Здесь находится ЦЕРН, Европейская организация ядерных исследований. В кольце Большого адронного коллайдера шириной 16 миль протоны сталкиваются друг с другом со скоростью, приближающейся к скорости света. Наш вид приматов воссоздает условия начала существования нашей Вселенной. БАК – это самое сложное оборудование, которое когда-либо было создано.

Впечатляющие инженерные решения БАКа сочетаются с беспрецедентным уровнем международного сотрудничества в ЦЕРНе. Ускоритель частиц начал функционировать в первом десятилетии XXI века, но фундамент был заложен более полувека назад. Именно тогда группа стран объединилась для создания Конвенции ЦЕРН, выделяя ресурсы и деньги на чисто научные исследования. Единственной прибылью от инвестиций, которую они ожидали, была валюта знаний.

 Эта основа создала уникальную среду, свободную от ограничений национальных, экономических и социальных иерархий. Лауреаты Нобелевской премии по физике сотрудничают со студентами во время летних стажировок. Если и существует элемент социальной категоризации в ЦЕРНе, то только между теоретиками и экспериментаторами. Теоретики – это те, у кого в кабинетах стоят доски. Экспериментаторы – это те, у кого есть компьютеры. Им приходится иметь дело с большим количеством данных. Еще до того, как был включен Большой адронный коллайдер, управление информацией было реальной проблемой в ЦЕРН.

Корешок книги. Спрашивать обо всем внутри

Это Тим Бернерс Ли, ученый-компьютерщик из Англии, который работал в ЦЕРНе в 1980-х. В начале того десятилетия он начал личный проект, чтобы разобраться с управлением информацией. Получившееся в результате программное обеспечение называлось ENQUIRE, названное в честь викторианского руководства по семейной жизни под названием Enquire Within On Everything.

К концу 80-х годов Тим Бернерс-Ли был готов к более масштабному решению сложной проблемы управления информацией. Чтобы получить поддержку в ЦЕРНе, он подготовил непритязательный документ под названием "Управление информацией: Предложение. К счастью, его начальник, Майк Сендалл, признал потенциал этой идеи и дал ход, написав слова "Смутно, но захватывающе…" в верхней части документа. Это предложение стало Всемирной паутиной.

Лист печатной бумаги с несколькими написанными от руки словами вверху. Смутно, но захватывающе…

Сегодня мы думаем о Всемирной паутине как об одном из величайших изобретений в истории коммуникации, но для ученых ЦЕРНа это просто побочный продукт.  Когда вы имеете дело с космологическими временными масштабами и исследуете сами строительные блоки реальности, хронология отношений человечества с технологиями – не более чем ошибка округления.

Когда Тим Бернерс-Ли решил заняться проблемой управления информацией в ЦЕРНе, Интернет уже стал частью его инфраструктуры. Эта сеть сетей была впервые создана в 1960-х годах, и первыми ее пользователями стали университеты и научные учреждения.

Эти узлы уже были физически соединены телефонными проводами. Вместо того, чтобы создавать совершенно новую сеть с нуля, имеет смысл повторно использовать то, что уже было. И вновь новая технология стала возможной только благодаря существованию более старой. В девятнадцатом веке мир был технологически терраформирован для телеграфа. Благодаря удивительным инженерным достижениям наша планета была соединена подводными кабелями. Позднее эти же кабели были перепрофилированы для передачи телефонных сигналов. Позже они снова будут нести цифровые единицы и нули Интернета. Сегодня эти сигналы передаются с помощью световых импульсов, проходящих по волоконно-оптическим кабелям. Эти оптоволоконные кабели проходят по дну океана теми же путями, что и их телеграфные предшественники.

Это карта подводных кабелей. Telegeography ежегодно публикует новую карту подводных кабелей.

Интернет не имеет центра. Это архитектурное решение придает сети надежность. Возможно, вы слышали, что Интернет был создан для того, чтобы противостоять ядерной атаке. Это не совсем верно. Это правда, что проект начался с военных соображений. Первоначальное исследование было профинансировано DARPA, Агентством перспективных оборонных проектов. Но инженеры, работавшие над проектом, не были военными. Их идеалы имели больше общего с движением за свободу слова, чем с военно-промышленным комплексом. Они спроектировали сеть так, чтобы обойти повреждения, но повреждения, о которых они беспокоились, были связаны с цензурой, а не с ядерной атакой. Открытая архитектура Интернета отражала либеральное мировоззрение его создателей. Помимо децентрализации, интернет был также намеренно спроектирован как "тупая" сеть. Это его секретный соус. Протоколы, лежащие в основе передачи данных в интернете – TCP/IP – описывают, как должны перемещаться пакеты данных, но эти протоколы нисколько не заботятся о содержимом пакетов. Это позволяет Интернету быть транспортным механизмом для всех видов приложений: электронной почты, Telnet, FTP и, в конечном счете, Всемирной паутины.

Для отправки и получения данных в Интернете используется протокол передачи гипертекста HTTP HyperText Transfer Protocol (Протокол передачи гипертекста). Эти данные однозначно идентифицируются с помощью URL-адреса. Многие из этих URL идентифицируют страницы, созданные на HTML – языке гипертекстовой разметки. Убийственная особенность Интернета заключается в скромном элементе A языка HTML. A означает Anchor (якорь). Его атрибут HREF позволяет переходить от одного URL к другому URL, создавая ссылку, по которой можно переходить от одной страницы к другой. Эти ссылки превращают Интернет из простой системы хранения и поиска информации в гипертекстовую систему.

Тим Бернерс Ли не изобретал гипертекст. Этот термин придумал Тед Нельсон, дальновидный ученый-компьютерщик, который работал над своей собственной гипертекстовой системой под названием Xanadu. На Теда Нельсона и Тима Бернерса Ли повлияли идеи, изложенные Ванневаром Бушем в его основополагающем эссе 1945 года As We May Think (Как мы можем думать). Буш, несомненно, в свою очередь, находился под влиянием идей бельгийского информатика Поля Отлета. Каждый из этих гигантов в истории гипертекста стоял на плечах гигантов, которые пришли до них. Гиганты до самого конца.

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

Однако простота Интернета оказалась секретом его успеха.

Тим Бернерс-Ли предположил, что большинство URL-адресов будут указывать на ресурсы, не относящиеся к HTML: документы текстового процессора, электронные таблицы и всевозможные другие компьютерные файлы. HTML можно было бы использовать для создания простых индексных страниц, указывающих на эти файлы с помощью ссылок. Поскольку HTML не нужно было делать много, он имел ограниченный словарный запас. Это сделало его относительно легким для изучения. К удивлению Тима Бернерс-Ли, люди начали создавать полноценные документы на HTML. Вместо того чтобы создавать содержимое в других форматах файлов и использовать HTML для связи между ними, люди стали писать содержимое непосредственно в HTML.

HTML не был первым языком разметки, который использовался в ЦЕРНе. ченые уже обменивались документами, написанными в стиле SGML-Standard Generalized Markup Language (стандартном обобщенном языке разметки). Тим Бернерс-Ли взял существующий в ЦЕРНе словарь SGML и использовал его в качестве отправной точки для своего нового языка разметки. И снова имело смысл опираться на то, с чем люди уже были знакомы, а не создавать что-то с нуля. Первая версия HTML содержала в общей сложности 21 элемент. Многие из этих элементов мы знаем и сегодня – TITLE, P, UL, LI, H1, H2 и т.д., и, конечно же, элемент A. Другие элементы канули в прошлое – ISINDEX, PLAINTEXT, LISTING, HP1, HP2 и т.д., а также собственный элемент NEXTID, который имел смысл только при использовании компьютера под управлением операционной системы NeXTSTEP. Именно эту ОС использовал Тим Бернерс-Ли, когда создал HTTP, HTML и первый в мире веб-браузер, названный непонятно как WorldWideWeb, который работал только на машинах NeXT.

Для демонстрации возможностей и совместимости Интернета был необходим кроссплатформенный браузер, который мог бы установить и использовать любой человек, независимо от того, какую операционную систему он использует. Задача создания этого браузера легла на студента ЦЕРН по имени Никола Пеллоу. Она создала браузер (Line Mode Browser). Он был простым, но мощным. Он не обладал таким уровнем интерактивности, как браузер WorldWideWeb, но тот факт, что его можно было запустить на любой машине, означал, что Интернет теперь доступен каждому.

Крупный план экрана с зеленым текстом на черном фоне. Браузер Line Mode Browser в действии.

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

Например, что должен делать браузер Line Mode , когда он встречает непонятный ему элемент HTML, такой как NEXTID?

Ответ можно найти в скудной документации, которую Тим Бернерс-Ли написал для своей первоначальной коллекции под названием HTML Tags. Под заголовком " NEXTID " он написал:

Программное обеспечение браузера может игнорировать этот тег.

Это безобидное на первый взгляд решение имело далеко идущие последствия для будущего Всемирной паутины.

Тим Бернерс‐Ли, улыбается. Сэр Тим Бернерс-Ли. Фотография Пола Кларка. Лицензировано по лицензии Creative Commons Attribution-ShareAlike 4.0 International.

Information Management: A proposal by Tim Berners-Lee

Telecom Maps by TeleGeography

As We May Think by Vannevar Bush

HTMLTags

Рискуя научить

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

<p>some text</p>

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

<marklar>some more text</marklar>

И снова браузер отображает текст между открывающим и закрывающим тегами. Здесь интересно то, что браузер не делает. Браузер не выдает ошибку. Браузер не останавливает разбор HTML на этом этапе, отказываясь идти дальше. Вместо этого он просто игнорирует теги и отображает содержимое внутри них.

Такое либеральное отношение к ошибкам позволило со временем расширить словарный запас HTML с первоначального 21 элемента до 121 элемента в HTML5. Каждый раз, когда в HTML появляется новый элемент, мы точно знаем, как к нему отнесутся старые браузеры: они будут игнорировать теги и отображать содержимое.

Это удивительно мощная функция. Она позволяет браузерам внедрять новые возможности HTML с разной скоростью. Нам не нужно ждать, пока каждый браузер распознает новый элемент. Вместо этого мы можем начать использовать новый элемент в любое время, будучи уверенными, что не поддерживающие его браузеры не подавятся им.

<main>this text will display in any browser</main>

Если веб-браузеры относятся ко всем тегам одинаково – отображают их содержимое – тогда какой смысл в наличии словаря элементов в HTML?

Некоторые элементы HTML буквально бессмысленны. Элемент SPAN ничего не говорит о содержимом внутри него. С точки зрения веб-браузера, вы можете использовать несуществующий элемент MARKLAR. Но это исключение. Большинство элементов HTML существуют не просто так. Они были созданы и согласованы для того, чтобы учитывать конкретные ситуации, с которыми могут столкнуться такие авторы, как вы и я.

Существуют специальные элементы, например, элемент A, которые наделены сверхспособностями. В случае с элементом A его суперспособность заключается в атрибуте HREF, который позволяет нам ссылаться на любой другой ресурс в Интернете. Другие элементы, такие как INPUT, SELECT, TEXTAREA и BUTTON, имеют свои собственные суперспособности, позволяя людям вводить данные и отправлять их на веб-сервер.

Кроме того, есть элементы, которые описывают содержание, которое они содержат. Содержимое элемента P следует рассматривать как абзац текста. Содержимое элемента LI следует рассматривать как элемент списка. Браузеры отображают содержимое этих элементов с некоторыми визуальными подсказками относительно их значения. Абзацы отображаются с пробелами до и после их содержимого. Элементы списка отображаются в виде точек или цифр перед их содержимым.

В начале развития лексикон HTML был наполнен новыми элементами, которые предоставляли визуальные инструкции веб-браузерам: BIG, SMALL, CENTER, FONT. На самом деле, визуальные инструкции были единственной причиной существования этих элементов – они не давали никакого намека на смысл содержимого, которое они содержали. HTML был в опасности превратиться в язык визуальных инструкций вместо словаря смысла.

Хокон Виум Ли работал в ЦЕРНе в то же время, что и Тим Бернерс-Ли. Он сразу же распознал потенциал Всемирной паутины и ее языка HTML. Он также понимал, что выразительные возможности языка могут быть перегружены визуальными функциями. Ли предложил новый формат для описания представления HTML-документов: Каскадные таблицы стилей.

Вскоре к нему присоединился голландский программист Берт Бос. Вместе они приступили к созданию синтаксиса, который был бы достаточно мощным для удовлетворения потребностей дизайнеров, оставаясь достаточно простым, чтобы быстро учиться. Им это удалось.

Подумайте обо всех сайтах в Интернете. Существует огромное разнообразие визуального стиля: цветовые схемы, типографика, текстуры и макеты. Все это разнообразие стало возможным благодаря одному простому шаблону, который описывает весь когда-либо написанный CSS:

selector {

property: value;

}

Вот и все.

CSS разделяет снисходительное отношение HTML к ошибкам. Если браузер встречает непонятный ему селектор, он просто пропускает все, что находится между фигурными скобками этого селектора. Если браузер видит непонятное ему свойство или значение, он просто игнорирует это конкретное правило. Браузер не выдает ошибку. Браузер не выбрасывает ошибку. Браузер не прекращает разбор CSS на данном этапе, отказываясь идти дальше.

marklar {

marklar: marklar;

}

Как и в HTML, такая свободная обработка ошибок позволила CSS развиваться со временем. За эти годы в словарь языка были добавлены новые селекторы, новые свойства и новые значения. Когда в CSS появляется новая функция, дизайнеры и разработчики знают, что могут смело использовать ее, даже если она еще не получила широкой поддержки в браузерах. Они могут быть уверены, что старые браузеры отреагируют на новые возможности с полным безразличием.

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

В 1996 году Дэвид Сигел опубликовал книгу под названием "Создание убийственных веб-сайтов". В ней он описал ряд гениальных приемов для создания привлекательного дизайна из исходного материала HTML.

Одна из техник предполагает использование прозрачного GIF, размером всего один пиксель на один пиксель. Если его вставить на страницу как элемент IMG, но задать точные значения атрибутов WIDTH и HEIGHT, то дизайнеры смогут контролировать количество пробельных элементов в своем дизайне.

Другая техника использует элемент TABLE. Этот элемент, а также его дочерние элементы TR и TD предназначались для описания табличных данных. Но при правильных значениях ширины и высоты ячеек таблицы его можно было использовать для воссоздания практически любого желаемого макета.

Это были хаки; умные решения сложных проблем. Но они имели печальные последствия. Дизайнеры относились к HTML как к инструменту для создания внешнего вида содержимого, а не как к языку для описания смысла содержимого. CSS был решением этой проблемы, если только дизайнеров можно было убедить использовать его.

Одной из причин, почему веб-дизайнеры не использовали CSS, было отсутствие поддержки браузера. Тогда были два основных браузера, конкурирующих за душу Интернета: Microsoft Internet Explorer и Netscape Navigator. Они были несовместимы по дизайну. Один браузер изобретал бы новый HTML-элемент или атрибут. Другой браузер изобретает свой собственный отдельный элемент или атрибут, чтобы делать точно то же самое.

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

Группа веб-дизайнеров решила, что хватит. Они собрались под знаменем проекта Web Standards Project и начали лоббировать Microsoft и Netscape, чтобы те отказались от своих проприетарных методов и приняли стандарты, такие как CSS.

Ситуация начала меняться с выходом Internet Explorer 5 для Mac, браузера, который поставлялся с впечатляющей поддержкой CSS. Если это было будущее веб-дизайна, то жизнь должна была стать гораздо более продуктивной и творческой.

Некоторые дальновидные веб-дизайнеры поймали ошибку CSS рано. Они переработали свои веб-сайты, используя CSS для макета, вместо использования TABLEs и spacer GIF. Будучи верными духу Интернета, они делились тем, чему учились, и призывали других перейти на CSS.

Некоторые дальновидные веб-дизайнеры рано поймали "жучка" CSS. Они изменили дизайн своих сайтов, используя CSS для верстки, вместо использования таблиц и распорных GIF. Верные духу основателей Интернета, они делились своими знаниями и призывали других перейти на CSS.

Возможно, лучшей демонстрацией возможностей CSS стал сайт под названием CSS Zen Garden, созданный Дейвом Ши. Это была витрина красивых и разнообразных дизайнов, все они были выполнены с помощью CSS. Важно отметить, что HTML остался прежним.

Выбор из множества дизайнов, созданных для CSS Zen Garden.

Видя, как один и тот же HTML-документ оформляется множеством различных способов, я убедился в одном из полезных эффектов CSS: разделении задач.

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

В тесно связанной системе каждая часть системы может делать предположения о других частях. Такие системы могут быть спроектированы довольно быстро, но за это приходится платить. Им не хватает устойчивости. Если одна часть выходит из строя, это может привести к отказу всей системы.

Проектирование слабосвязанной системы может потребовать больше работы. Платой за это является то, что общий результат более устойчив к сбоям. Отдельные части системы могут быть заменены с минимальными последствиями.

Хакеры, пионером которых был Дэвид Сигел, жестко связывали структуру и представление в единый монолитный HTML-файл. Принятие CSS ослабило эту зависимость, приблизив веб к модульному подходу философии UNIX. Презентационная информация может быть перенесена в отдельный файл – таблицу стилей. Вот почему к одному HTML-документу в CSS Zen Garden может быть применено так много различных дизайнов.

Таблица стилей по-прежнему должна обладать некоторыми знаниями о структуре HTML-документа. Довольно часто в разметку добавляются "крючки", облегчающие стилизацию: например, определенные значения атрибутов CLASS или ID. Таким образом, HTML и CSS не полностью разделены. Они образуют партнерство, но у них есть и договоренность. Документ разметки может решить, что иногда он хочет попробовать увидеть другие таблицы стилей. Между тем, таблица стилей потенциально может быть применена к другим документам. Они слабо связаны друг с другом.

Для того чтобы сформировать собственные ценности дизайна, требуется время. Веб-дизайн – действительно молодая дисциплина. Пока мы медленно начинаем формировать свой собственный набор руководящих принципов, мы можем обратиться за вдохновением к другим дисциплинам.

Мир архитектуры за многие годы накопил свой собственный набор ценностей дизайна. Одна из них – принцип честности материалов. Один материал не должен использоваться в качестве заменителя другого. Иначе конечный результат будет обманчивым.

Использование таблиц TABLE для верстки – это материальная нечестность. Элемент TABLE предназначен для разметки структуры табличных данных. Конечный результат использования ТАБЛИЦ, элементов FONT и проставочных GIF – это фасад. На первый взгляд все выглядит хорошо, но при проверке это не выдерживает критики. Как только такой сайт подвергается стресс-тестированию при реальном использовании в различных браузерах, фасад рушится.

Использование CSS для представления материала является честным – это целевое использование CSS. Он также позволяет HTML быть честным в материальном плане. Вместо того чтобы пытаться выполнять две роли – структуры и представления – HTML может вернуться к выполнению своей истинной цели – разметке смысла содержимого.

По-прежнему можно использовать (или злоупотреблять) CSS, чтобы быть материально нечестным. Долгое время не существовало простого способа добавить закругленные углы к элементу с помощью CSS. Вместо этого веб-дизайнеры находили способы обойти эту проблему, накладывая на элемент фоновые изображения для имитации того же конечного эффекта. Это работало до определенного момента, но, как и в случае с проставкой GIF, это был фасад. Затем появилось свойство border-radius. Теперь дизайнеры могли получить свои закругленные углы честным с материальной точки зрения способом.

Важно отметить, что дизайнеры смогли использовать новые свойства, такие как border-radius, задолго до того, как их стали поддерживать все веб-браузеры. Все это благодаря либеральной модели обработки ошибок CSS. Новые браузеры отображали закругленные углы. Более старые браузеры не выдавали ошибку. Старые браузеры не прекращали разбор CSS и не отказывались разбирать его дальше. Они просто игнорировали бы непонятные инструкции и шли дальше. Ни вреда, ни вреда.

Конечно, это означает, что получившийся сайт будет выглядеть по-разному в разных браузерах. Некоторые люди увидят закругленные углы. Другие – нет.

И это нормально.

TheWebis RuinedandI RuineditbyDavid Siegel

CSS Zen Gardenby Dave Shea

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

Келлская книга – это прекрасно иллюстрированный манускрипт, созданный более 1200 лет назад. Заманчиво назвать ее произведением искусства, но это произведение дизайна. Цель книги – передать послание; Евангелия христианской религии. Благодаря использованию иллюстраций и каллиграфии это послание передается в привлекательном контексте, что делает его приятным для созерцания.

Начало Евангелия от Матфея в Келлской книге.

Дизайн работает в рамках ограничений. Колумбанские монахи, которые создали Келлскую книгу, работали с четырьмя чернилами на пергаменте, материале из телячьей кожи. Материалы были простыми, но четко определенными. Сенобистические дизайнеры знали оттенки чернил, вес пергамента, и, самое главное, они знали размеры каждой страницы.

Материалы и процессы менялись и развивались на протяжении последнего тысячелетия или около того. Изобретение Гутенбергом подвижного шрифта стало революцией в производстве. Если на создание второй копии Книги Келлса ушло бы столько же времени, сколько на создание первой, то многочисленные копии Библии Гутенберга можно было изготовить с гораздо меньшими затратами труда. Несмотря на это, многие детали оформления, такие как каплевидные колпачки и колонны, были перенесены из иллюминированных рукописей. Фундаментальный процесс дизайна остался прежним: зная ширину и высоту страницы, дизайнеры создавали приятное расположение элементов.

Страница из Библии Гуттенберга.

Техника печатного дизайнера достигла своего зенита в 20 веке с появлением швейцарского стиля. Его структурированная верстка и четкая типографика являются примером работы таких дизайнеров, как Йозеф Мюллер-Брокманн и Ян Чихольд. Они разработали системы сетки и типографские шкалы на основе дизайна предыдущих веков.

Рамка для средневековых рукописей Яна Чихольда.

Зная соотношение размеров страницы, дизайнеры могли размещать элементы с максимальным эффектом. Страница – это ограничение, а система сетки – способ навязать ей порядок.

Когда в 1990-х годах Интернет начал завоевывать мир, дизайнеры начали переходить с бумаги на пиксели. Книга Дэвида Сигела "Создание убийственных веб-сайтов" появилась как раз в это время. Его умные TABLE и GIF-хаки позволили дизайнерам воспроизвести те же макеты, которые они ранее создавали для печатной страницы.

Эти макеты TABLE позже стали макетами CSS, но фундаментальное мышление осталось прежним: окно браузера, как и страница до него, рассматривалось как известное ограничение, на которое дизайнеры накладывали порядок.

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

Дизайнеры привыкли знать размеры прямоугольников, в пределах которых они проектировали. Интернет устранил это ограничение.

Ничто так не пугает, как неизвестность. Эти слова бывшего министра обороны США Дональда Рамсфельда должны вызывать настоящий ужас (хотя в то время общее мнение было таково, что они звучали как бред):

«…Как мы знаем, есть известные нам известные; есть вещи, которые мы знаем, что мы знаем. Мы знаем также, что есть известные неизвестные: то есть мы знаем, что есть вещи, которых мы не знаем. Но есть и неизвестные неизвестные – те вещи, о которых мы не знаем, что мы их не знаем»

Дональд Рамсфельд

Соотношение окна браузера является лишь одним примером неизвестного в Интернете. Самый простой способ справиться с этой ситуацией заключается в использовании гибких единиц для макета: проценты, а не пиксели. Вместо этого дизайнеры решили сделать вид, что размеры браузера известны. Они создали фиксированную ширину макетов для одного конкретного размера окна.

На заре развития Интернета большинство мониторов имели ширину 640 пикселей. Веб-дизайнеры создавали макеты шириной 640 пикселей. Когда все больше людей стали использовать мониторы с шириной 800 пикселей, все больше дизайнеров стали создавать макеты шириной 800 пикселей. Через несколько лет это значение стало равным 1024 пикселям. В какой-то момент веб-дизайнеры остановились на магическом числе 960 пикселей как на идеальной ширине.

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

Не все согласились с этой памяткой, распространяемой по сети.

В 2000 году онлайн-журнал A List Apart опубликовал статью под названием A Dao Of Web Design ("Дао веб-дизайна"). Она прекрасно выдержала испытание временем.

В статье Джон Оллсопп указывает на то, что новые медиа часто начинают с того, что берут на вооружение тропы предыдущих медиа. Скотт Макклауд говорит о том же в своей книге "Понимание комиксов":

«Каждый новый способ передачи информации, начинает свою жизнь с попытки имитировать своих предшественников. Множество ранних фильмов были отснятыми театральными пьесами, самое раннее телевидение было похоже на радио с картинками или коротенькими фильмами.»

Скотт Маклауд

Учитывая это, неудивительно, что веб-дизайн начался с попыток воссоздать те виды макетов, которые были знакомы дизайнерам из мира печати. Как сказал Джон:

«Сайты-убийцы" – это обычно те, которые укрощают необузданность Интернета, ограничивая страницы, как если бы они были сделаны из бумаги – Настольная публикация для Интернета.»

Джон Оллсопп

Веб-дизайн может извлечь пользу из многовекового опыта, который лег в основу печатного дизайна. Массимо Виньелли, чьи работы олицетворяют швейцарский стиль, начинает свой знаменитый "Канон" с перечня нематериальных ценностей, включая дисциплину, уместность, вневременность, ответственность и многое другое. Все из этого списка можно применить к дизайну для Интернета. Канон Виньелли также включает в себя список осязаемых качеств. Этот список начинается с размеров бумаги.

Интернет – это не печать. Известные ограничения бумаги – ее ширина и высота – просто не существуют. Веб не связан заранее установленными размерами. Книга Джона Оллсоппа "Дао веб-дизайна" призывает практиков признать это:

Плох тот мастер, который всегда винит свои инструменты. И все же каждый ремесленник находится под влиянием своего выбора инструментов. Как сказал коллега Маршалла Маклюэна Джон Калкин, "мы формируем наши инструменты, а затем наши инструменты формируют нас".

Когда зарождалась дисциплина веб-дизайна, не существовало программного обеспечения, созданного специально для визуализации макетов в Интернете. Вместо этого дизайнеры использовали существующие инструменты.

Adobe Photoshop изначально предназначался для работы с изображениями: корректировка фотографий, применение фильтров, компоновка слоев и так далее. К середине девяностых годов он стал незаменимым инструментом для графических дизайнеров. Когда те же дизайнеры начали разрабатывать дизайн для Интернета, они продолжили использовать уже знакомое им программное обеспечение.

Если вы когда-либо пользовались Photoshop, то вы знаете, что происходит, когда вы выбираете "New" в меню "File": вам будет предложено ввести фиксированные размеры холста, на котором вы собираетесь работать. Прежде чем добавить один пиксель, было принято фундаментальное дизайнерское решение, которое усиливает консенсусную галлюцинацию о негибкой сети.

Photoshop сам по себе не может взять на себя вину за мышление с фиксированной шириной. В конце концов, он никогда не предназначался для разработки веб-страниц. В конце концов, было выпущено программное обеспечение, предназначенное именно для создания веб-страниц. Dreamweaver от Macromedia был ранним примером инструмента для веб-дизайна. К сожалению, он работал в соответствии с идеей WYSIWYG: "Что видишь, то и получаешь".

Хотя это правда, что при разработке в Dreamweaver то, что вы видите, это то, что вы получаете, в Интернете нет гарантии, что то, что вы видите, это то, что получат все остальные. В очередной раз веб-дизайнерам было предложено принять иллюзию контроля, вместо того чтобы столкнуться с неопределенностью, присущей их среде.

Можно преодолеть встроенные предубеждения таких инструментов, как Photoshop и Dreamweaver, но это нелегко. Нам хотелось бы думать, что мы контролируем наши инструменты, что мы подчиняем их своей воле, но правда в том, что все программное обеспечение – это программное обеспечение, основанное на мнениях. Как сказал футурист Джамайс Касио, "программное обеспечение, как и все технологии, по своей сути является политическим":

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

«Код неизбежно отражает выбор, предубеждения и желания его создателей.»

Джамайс Касио

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

К середине первого десятилетия двадцать первого века область веб-дизайна опиралась на множество предположений:

что все просматривали веб-страницы с экраном, достаточно большим для просмотра макета шириной 960 пикселей;

что все имели широкополосный доступ в Интернет, что уменьшало необходимость оптимизации количества и размера файлов изображений на веб-страницах;

все пользовались современным веб-браузером с установленными последними плагинами.

Меньшинство веб-дизайнеров все еще умоляли о жидких макетах. Я причислял себя к их числу. Нас терпели примерно так же, как пророка судьбы на углу улицы с доской для сэндвичей с надписью "Конец близок" – неудобное, но безобидное отвлечение внимания.

Были даже дизайнеры, которые говорили, что Photoshop, возможно, не лучший инструмент для работы в Интернете, и что мы можем рассмотреть возможность разработки непосредственно в браузере с использованием CSS и HTML. Такой подход был раскритикован как слишком ограничивающий. Как мы видели, у Photoshop есть свои ограничения, но они были усвоены дизайнерами, которым было настолько удобно пользоваться этим инструментом, что они перестали признавать его недостатки.

«iPod. Телефон. И интернет-коммуникатор. iPod. Телефон… вы поняли? Это не три отдельных устройства. Это одно устройство. И мы называем его: iPhone.»

С этими словами в 2007 году Стив Джобс представил мобильное устройство, которое можно было использовать для просмотра страниц во Всемирной паутине.

iPhone.

Мобильные устройства с возможностью работы в Интернете существовали и до появления iPhone, но они в основном были ограничены отображением специализированного формата файлов, удобного для мобильных устройств, под названием WML. Очень немногие устройства могли отображать HTML. С появлением iPhone и его конкурентов портативные устройства стали поставляться с современными веб-браузерами, способными быть первоклассными гражданами в Интернете. Это повергло область веб-дизайна в шок.

Предположения, которые легли в основу целой отрасли, теперь были поставлены под сомнение:

Как узнать, используют ли люди широкие экраны настольных компьютеров или узкие экраны телефонов?

Как узнать, пользуются ли люди дома быстрым широкополосным соединением или медленной мобильной сетью?

Как узнать, поддерживает ли устройство ту или иную технологию или плагин?

Рост мобильных устройств столкнул веб-дизайнеров с истинной природой интернета как гибкой среды, полной неизвестных.

Первоначальной реакцией на эту вновь открывшуюся реальность стала сегментация. Вместо того чтобы пересматривать существующий сайт, оптимизированный для настольных компьютеров, что если бы мобильные устройства можно было отвести в отдельный бункер? Это мобильное гетто часто располагалось на отдельном поддомене "настоящего" сайта: m.example.com или mobile.example.com.

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

Для определения того, какие устройства отправляются на тот или иной поддомен, требовалось проверить строку пользовательского агента браузера по постоянно расширяющемуся списку известных браузеров. Это была гонка Красной Королевы, чтобы просто оставаться в курсе событий. Помимо того, что это было чревато ошибками, это было еще и довольно произвольно. Если раньше было легко классифицировать, скажем, iPhone как мобильное устройство, то со временем это различие становилось все сложнее. С появлением планшетов, таких как iPad, стало неясно, какие устройства следует перенаправлять на мобильный URL. Возможно, был создан новый поддомен for-t.example.com или tablet.example.com – вместе с новым термином "планшетный веб". Но как насчет "телевизионного интернета" или "интернета холодильника"?

Практика создания разных сайтов для разных устройств просто не подходит. Это также противоречило давнему идеалу под названием "Единый веб":

«Единый веб означает предоставление, насколько это разумно, одинаковой информации и услуг пользователям независимо от используемого ими устройства.

В апреле 2010 года Итан Маркотт выступил на сцене An Event Apart в Сиэтле, где собирались люди, создающие веб-сайты. Он говорил об интересной школе мысли в мире архитектуры: отзывчивый дизайн, идея о том, что здания могут меняться и адаптироваться в зависимости от потребностей людей, использующих здание. Это, как он объяснил, может стать способом подхода к созданию веб-сайтов.

Месяц спустя он развил эту идею в статье под названием Responsive Web Design ("Отзывчивый веб-дизайн"). Он был опубликован на А List Apart, том же веб-сайте, который опубликовал John Allsopp's A Dao Of Web Design десять лет назад. Статья Итана разделяла тот же дух, что и предыдущий громкий крик Джона. На самом деле, Итан начинает свою статью со ссылки на А Dao Of Web Design ("Дао веб-дизайна").

Обе статьи призывали веб-дизайнеров принять идею Единого Веба. Но если Dao Of Web Design ("Дао веб-дизайна") был в основном отвергнут дизайнерами, которым было удобно работать с инструментами WYSIWYG, то Responsive Web Design ("Отзывчивый веб-дизайн") нашел свою аудиторию среди дизайнеров, отчаянно пытающихся решить проблему мобильных устройств.

Писатель Стивен Джонсон задокументировал историю изобретений и инноваций. В своей книге Where Good Ideas Come From ("Откуда берутся хорошие идеи") он исследует идею под названием "смежные возможности":

«В каждый момент времени расширяющейся биосферы есть двери, которые пока не могут быть открыты. В человеческой культуре, мы любим думать о прорывных идеях как о внезапных ускорениях во времени, где гений прыгает на 50 лет вперед и изобретает что-то, что обычные умы, запертые в настоящем моменте, не могли бы придумать. Но истина заключается в том, что технологические (и научные) достижения редко появляются из соседних возможных; история культурного прогресса почти без исключения – это история одной двери, ведущей к другой, исследуя дворец в одной комнате за другой.»

Стивен Джонсон

Именно поэтому микроволновая печь не могла быть изобретена в средневековой Франции; для такого скачка требуется слишком много предшествующих шагов – производство, энергия, теория. Facebook не мог существовать без Всемирной паутины, которая не могла существовать без Интернета, который не мог существовать без компьютеров, и так далее. Каждый шаг зависит от накопленных ниже уровней.

К тому времени, когда Итан ввел термин "отзывчивый веб-дизайн", ряд технологических достижений уже был на месте. Как я написал в предисловии к последующей книге Итана на эту тему:

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

Люк Вроблевски придумал термин Mobile First в ответ на рост популярности мобильных устройств:

«Потеря 80% экранного пространства заставляет вас сосредоточиться. Вы должны быть уверены, что на экране останется только самый важный набор функций для ваших клиентов и вашего бизнеса. Здесь просто нет места для всякого мусора интерфейса или контента сомнительной ценности. Вы должны знать, что имеет наибольшее значение.»

A Dao of Web Design by John Allsopp

The Vignelli Canon by Massimo Vignelli

Openness and the Metaverse Singularity by Jamais Cascio

One Web by Jo Rabin and Charles McCathieNevile

Responsive Web Design by Ethan Marcotte

A Richer Canvas by Mark Boulton

Fit To Scale by Trent Walton

Long Live the Web: A Call for Continued Open Standards and Neutrality by Tim Berners‐Lee

Джон Постел был одним из

инженеров, работавших над ARPANET, предшественницей Интернета. Он хотел убедиться, что пакеты или "дейтаграммы", перемещающиеся по сети, доставляются наиболее эффективным способом. Он понял, что небрежное отношение к ошибкам имеет решающее значение для эффективной коммутации пакетов.

Джон Постел.

Фотография Ирен Фертик, Служба новостей Университета Южной Калифорнии.

Авторское право 1994, USC.

Если узел в сети получает дейтаграмму с ошибками, но все еще понятную, то пакет должен быть обработан в любом случае. И наоборот, каждый узел в сети должен стараться отправлять хорошо сформированные пакеты. Эта линия мышления была закреплена в Принципе устойчивости, также известном как Закон Постеля:

«Будьте консервативны в том, что вы посылаете; будьте либеральны в том, что вы принимаете.»

Если это звучит знакомо, то это потому, что именно таким образом веб-браузеры работают с HTML и CSS. Даже если в HTML или CSS есть ошибки, браузер все равно попытается обработать информацию, пропуская все фрагменты, которые он не может разобрать.

HTML и CSS являются примерами декларативных языков. Автор, пишущий на декларативном языке, описывает желаемый результат, не предоставляя пошаговых инструкций компьютеру, обрабатывающему файл. В HTML вы можете описать характер содержимого – параграфы, заголовки, поля формы и т.д. – без необходимости объяснять, что именно браузер должен делать с этой информацией. С помощью CSS можно описать желаемый внешний вид содержимого – цвета, границы и т.д. – без необходимости писать программу для применения этих стилей.

Большинство языков программирования не являются декларативными, они императивные. Perl, Java, C++ … все это примеры императивных языков. Если вы пишете на одном из этих языков, вы должны дать точные инструкции компьютеру, интерпретирующему ваш код.

Императивные языки предоставляют вам больше возможностей и точности, чем декларативные языки. За это приходится платить. Императивные языки, как правило, труднее изучать, чем декларативные. Кроме того, к императивным языкам сложнее применить закон Постеля. Если вы допустите одну ошибку – одну неправильно поставленную запятую или точку с запятой – вся программа может не сработать. Неправильно написанный тег в HTML или пропущенная фигурная скобка в CSS также могут стать причиной головной боли, но императивные программы должны быть хорошо сформированы, иначе они вообще не будут выполняться.

Императивные языки, такие как PHP, Ruby и Python, можно найти на серверах, питающих Всемирную паутину, читающих и записывающих записи баз данных, обрабатывающих входные данные и выполняющих сложные алгоритмы. Вы можете выбрать практически любой язык программирования при написании кода на стороне сервера. В отличие от неизвестности веб-браузера конечного пользователя, вы можете контролировать возможности своего сервера.

Если вы хотите писать императивный код, который работает в веб-браузере, у вас есть только один выбор: JavaScript.

Идея выполнения программы изнутри веб-страницы так же стара, как и сам веб. Вот раннее письмо в список рассылки www-talk:

«Я хотел бы знать, расширил ли кто-нибудь WWW так, чтобы можно было запускать произвольные программы нажатием кнопки в WWW-браузере.»

JavaScript дал дизайнерам возможность обновлять веб-страницы даже после их загрузки. Вскоре появились два распространенных способа использования: ролловеры и валидация форм.

Смена изображений при наведении курсора на ссылку может показаться не совсем разумным использованием совершенно нового языка программирования, но в девяностые годы не было другого способа создания эффектов наведения.

До появления JavaScript форма должна была быть отправлена на веб-сервер, прежде чем вы могли убедиться, что все необходимые поля заполнены, или что введенная информация соответствует ожидаемому формату.

Оба этих варианта использования все еще существуют, но теперь нет необходимости обращаться к JavaScript. Вы можете создавать эффекты перелистывания с помощью псевдокласса :hover в CSS. Вы можете проверять поля формы с помощью атрибутов REQUIRED и TYPE в HTML.

Эта схема повторяется снова и снова: решение создается на императивном языке и, если оно достаточно популярно, со временем переходит на декларативный язык. Когда функция доступна на декларативном языке, ее не только легче написать, но и она более надежна.

Свободная обработка ошибок в HTML и CSS означает, что многие авторские ошибки или проблемы с поддержкой браузера решаются изящно; браузер просто игнорирует то, что он не понимает, и продолжает работу. Этого часто бывает достаточно. В отличие от этого, если вы предоставите браузеру плохо сформированный JavaScript или попытаетесь использовать неподдерживаемую функцию JavaScript, браузер не только выдаст ошибку, но и прекратит разбор сценария на этом этапе и откажется работать дальше.

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

Одно из первых злоупотреблений JavaScript произошло (что неудивительно) в рекламной индустрии – бизнесе, смысл существования которого часто противоречит целям людей, пытающихся решить задачу как можно быстрее. JavaScript позволяет создавать новые окна браузера, что раньше мог делать только пользователь. Молодой разработчик по имени Итан Цукерман понял, что он может создавать новое окно с рекламой в нем. Это позволило рекламодателям разместить свое сообщение перед посетителями сайта. Мало того, JavaScript можно было использовать для создания нескольких окон, некоторые из которых были видимыми, а некоторые – скрытыми за текущим окном. Это было чудовищное решение.

Двадцать лет спустя Цукерман написал:

«Я написал код для запуска окна и запуска рекламы в нем. Мне очень жаль.»

Всплывающие (и не всплывающие) окна стали настолько невыносимыми, что браузеры должны были предоставить людям возможность блокировать их.

Рекламная индустрия позже нашла другие способы злоупотребления JavaScript. Реклама, поддерживаемая онлайн-издателями, вводила раздутый и неэффективный JavaScript в их страницы, что замедляло их загрузку. JavaScript также использовался для отслеживания людей с сайта на сайт. Для борьбы с этим люди потянулись к программам блокировки рекламы. В конечном итоге блокировка рекламы была встроена в браузеры и операционные системы, чтобы дать нам возможность бороться с чрезмерным JavaScript.

Веб-дизайнерам стоит помнить то, что рекламная индустрия предпочитает игнорировать: в Интернете последнее слово остается за пользователем.

В деле "Якобеллис против Огайо", рассмотренном Верховным судом в 1964 году, судья Поттер Стюарт дал такое определение непристойности:

«Я знаю это, когда вижу.»

То же самое можно сказать о Веб 2.0 или о термине "веб-приложение". Мы все можем привести примеры веб-приложений, но дать определение этому термину гораздо сложнее. Веб-приложения позволяют людям создавать, редактировать и удалять контент. Но эти задачи были распространены задолго до появления веб-приложений. Люди могли заполнять формы и отправлять их на веб-сервер для обработки. Ajax устранил необходимость в таком путешествии на сервер.

Возможно, определение веб-приложения требует некоторых круговых рассуждений:

JavaScript – это требование для веб-приложения, а

веб-приложение – это веб-сайт, для работы которого требуется JavaScript.

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

Рост JavaScript ускорился в 2005 году, когда Джесси Джеймс Гарретт опубликовал статью под названием Ajax: Новый подход к веб-приложениям. Статья дала название технике, которая набирала популярность. Используя определенный набор JavaScript, веб-браузер мог отправлять и получать данные с веб-сервера без обновления всей страницы. В результате пользователи получили более широкий доступ к информации.

Термин Ajax был придуман в то же время, когда на подъеме находился другой неологизм. Тим О'Рейли использовал фразу Web 2.0 для описания новой волны веб-продуктов и услуг. В отличие от Ajax, было трудно дать определение Web 2.0. Для бизнесменов это означало новые бизнес-модели. Для графических дизайнеров он означал закругленные углы и градиенты. Для разработчиков это означало JavaScript и Ajax.

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

Свободная обработка ошибок в HTML позволила ему со временем набрать силу. Это также обеспечило простоту изучения языка. Даже если вы допустили ошибку, реализация браузером закона Постеля гарантировала, что вы все равно получите результат. Удивительно, но была попытка удалить эту суперспособность из HTML.

После стандартизации HTML версии 4 в 1999 году Консорциум Всемирной паутины опубликовал XHTML 1.0. В нем HTML был переформулирован в соответствии с правилами формата данных XML. В то время как в HTML имена тегов и атрибутов могут быть прописными или строчными, XML требует, чтобы они были полностью строчными. Были и другие различия: все атрибуты должны быть заключены в кавычки, а отдельные элементы, такие как IMG или BR, требуют закрывающей косой черты.

XHTML 1.0 не добавил в язык никаких новых возможностей. Это был просто более строгий способ написания разметки. XHTML 2.0 был совсем другим предложением. Он не только удалял такие устоявшиеся элементы, как IMG, но и внедрял драконовскую модель обработки ошибок XML. Если в XML-документе есть хоть одна ошибка – один атрибут без кавычек или пропущенная закрывающая косая черта – то синтаксический анализатор должен немедленно остановиться и отказаться что-либо отображать.

XHTML 2.0 умер на лозе. Его теоретическая чистота была отвергнута людьми, которые действительно зарабатывали на жизнь созданием веб-сайтов. Веб-дизайнеры справедливо отказались от публикации в формате, который может полностью провалиться вместо того, чтобы попытаться восстановиться после ошибки.

Странно, что спустя годы веб-дизайнеры с удовольствием создавали целые веб-сайты с помощью JavaScript, языка, который разделяет неумолимую модель обработки ошибок XML. Они не называли их веб-сайтами. Они называли их веб-приложениями. Это различие было холодным утешением для тех, кто не мог выполнить свою задачу из-за того, что сервис полагался на JavaScript для критически важной функциональности.

Несмотря на хрупкую модель обработки ошибок JavaScript, веб-дизайнеры со временем все больше полагались на JavaScript. В 2015 году NASA перезапустило свой веб-сайт как веб-приложение. Если вы хотели прочитать последние новости о работе агентства по освоению космоса, вам сначала нужно было загрузить и выполнить три мегабайта JavaScript. Это содержимое – текст и изображения – могло быть передано в HTML, но разработчики решили использовать Ajax для получения этих данных. Пока весь этот JavaScript не был загружен, разобран и выполнен, посетители сайта смотрели на черный фон. Возможно, это было задумано как демонстрация огромной одинокой пустоты космоса.

Версия сайта nasa.gov 2015 года с неполным JavaScript.

Это подчеркивает еще одно различие между HTML и JavaScript. В то время как HTML можно просматривать по частям по мере загрузки, файл JavaScript должен быть загружен полностью, прежде чем его содержимое будет разобрано. Хотя очень заманчиво думать, что лишь небольшое меньшинство посетителей сайта пропустит JavaScript, правда заключается в том, что все являются пользователями без JavaScript до тех пор, пока JavaScript не закончит загрузку… если JavaScript закончит загрузку. Нестабильные соединения, вмешательство операторов сети и непредсказуемое программное обеспечение, блокирующее рекламу, могут разрушить предположение о том, что JavaScript всегда будет доступен.

Проблема не в том, что люди намеренно отключают JavaScript в своих браузерах. Хотя такой вариант использования стоит рассмотреть, это не самая распространенная причина ошибок JavaScript. Стюарт Лэнгридж составил список всех потенциальных точек отказа под заголовком "У всех есть JavaScript, верно?

«Пользователь запрашивает ваше веб-приложение. Загрузилась ли страница? Успешен ли HTTP-запрос для JavaScript? Завершился ли HTTP-запрос для JavaScript? Блокирует ли корпоративный брандмауэр JavaScript? Не препятствует ли провайдер или оператор мобильной связи загрузке JavaScript? Отключили ли они JavaScript? Установлены ли у них дополнения или плагины, которые внедряют сценарий или изменяют DOM таким образом, как вы не ожидали? Работает ли сеть доставки контента? Поддерживает ли их браузер написанный вами JavaScript?»

Многие из этих проблем также могут повлиять на файлы HTML и CSS, но благодаря закону Постеля они могут изящно восстановиться.

Это не означает, что веб-дизайнеры не должны использовать JavaScript. Но это означает, что веб-дизайнеры не должны полагаться на JavaScript, когда существует более простое решение.

Веб-дизайнеры, проигнорировавшие посыл книги Джона Оллсоппа "Дао веб-дизайна", совершили ошибку, отнесясь к вебу как к печатной продукции. История печати может многое предложить – иерархию, типографику, теорию цвета, но веб – это принципиально иной носитель информации. История разработки программного обеспечения также может многое предложить – архитектуру, тестирование, процесс, но, опять же, веб остается собственным носителем информации.

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

Язык, который мы используем, может тонко влиять на наше мышление. В своей книге "Метафоры, которыми мы живем" Джордж Лакофф подчеркивает опасность политического языка. Очевидными примерами являются "дружественный огонь" и "сопутствующий ущерб", но более коварным примером является "облегчение налогового бремени" – еще до начала дебатов налогообложение было представлено как нечто, требующее облегчения.

На первый взгляд, термин "веб-платформа" кажется безобидным. Описание веба как платформы ставит его в один ряд с другими программными средами. Flash был платформой. Android – это платформа. iOS – это платформа. Но веб – это не платформа. Вся идея веба в том, что он кроссплатформенный.

Платформа обеспечивает контролируемую среду выполнения для программного обеспечения. Пока у пользователя есть эта среда выполнения, вы можете быть уверены, что он получит именно то, что вы задумали. Если вы создаете приложение для iOS и у кого-то есть устройство iOS, вы знаете, что он получит 100% вашего программного обеспечения. Но если вы создадите приложение для iOS, а у кого-то будет устройство Android, он получит 0% вашего программного обеспечения. Вы не можете установить приложение iOS на устройство Android. Все или ничего.

Веб не так бинарен. Если вы создаете что-то с использованием веб-технологий, а кто-то заходит на сайт с помощью веб-браузера, вы не можете быть уверены, сколько веб-технологий будет поддерживаться. Скорее всего, это будет не 100%. Но также маловероятно, что это будет 0%. Некоторые люди будут посещать сайт с устройств iOS. Другие будут посещать сайт с устройств Android. Некоторые люди получат 80% или 90% того, что вы разработали. Другие получат только 20%, 30% или 50%. Интернет – это не платформа. Это континуум.

Думать о вебе как о платформе – это ошибка. Такие платформы, как Flash, iOS или Android, обеспечивают стабильность и определенность, но только при очень специфическом наборе обстоятельств – доступ к вашему программному обеспечению должен осуществляться с помощью соответствующей среды выполнения, специфичной для данной платформы. Интернет не дает такой уверенности, но он также не ограничивает возможные среды выполнения.

Платформы контролируемы и предсказуемы. Всемирная паутина хаотична и непредсказуема. В Интернете царит полный беспорядок.

RFC 761: Transmission Control Protocol by Jon Postel

Program Links in WWW by Tim Berners‐Lee

The Internet’s Original Sin by Ethan Zuckerman

Ajax: A New Approach to Web Applications by Jesse James Garrett

Everyone has JavaScript, right? by Stuart Langridge

В своей классической книге

"Как здания учатся" Стюарт Брэнд освещает идею британского архитектора Фрэнка Даффи:

«Правильно задуманное здание имеет несколько слоев долговечности.»

Даффи называл эти срезающие слои. Каждый из них движется в разных временных масштабах. Бренд развил идею, предложив шесть аллитеративных слоев:

Место – физическое расположение здания меняется только в геологическом масштабе.

Структура – само здание может стоять веками.

Внешняя отделка – внешняя поверхность здания обновляется каждые несколько десятилетий.

Обслуживание – водопровод и электропроводка нуждаются в обновлении каждые десять лет или около того.

План помещения – расположение стен и дверей может периодически меняться.

Вещи – расположение мебели в комнате может меняться ежедневно.

Разделение слоев.

Идею срезания слоев можно применить и к нашим творениям в Интернете. Наши доменные имена – это геологические объекты, на которых мы строим. На другом конце временной шкалы контент в Интернете – "материал" – может добавляться и обновляться ежечасно, ежеминутно или даже посекундно. Между ними находятся слои структуры, представления и поведения: HTML, CSS и JavaScript.

Эти слои могут быть слабо связаны друг с другом, но они не являются полностью независимыми. Как в здании не может быть мебели без комнат и стен, так и таблица стилей нуждается в разметке, чтобы действовать на ее основе. Связь между структурой и представлением осуществляется с помощью селекторов в CSS: селекторов элементов, селекторов классов и т. д. В JavaScript связь осуществляется через словарь объектной модели документа, или DOM (Document Object Model).

В более поздней книге "Часы долгого времени" Стюарт Брэнд применил идею срезания слоев – или темповых слоев – к самой цивилизации. Самый медленный слой – это природа, затем идет культура, за ней – управление, затем – инфраструктура, и, наконец, торговля и мода – самые быстрые слои. Каждый слой зависит от нижележащего. В свою очередь, накопление каждого последующего слоя позволяет создать "соседний возможный", наполненный еще большими возможностями.

Аналогичным образом, выразительность CSS и JavaScript возможна только на основе HTML, который сам по себе требует URL для доступа, который, в свою очередь, зависит от протокола передачи гипертекста, лежащего на фундаменте TCP/IP.

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

В 2003 году фестиваль South by Southwest в Остине, штат Техас, был в первую очередь мероприятием для музыкантов и кинематографистов. Сегодня музыкальная и кинематографическая части затмевают по значимости South by Southwest Interactive, посвященный всему цифровому. В 2003 году South by Southwest Interactive была небольшим мероприятием, втиснутым в один угол одного этажа Остинского конференц-центра. Это был шанс для нескольких веб-дизайнеров и блоггеров собраться вместе и обменяться идеями. В тот год Стивен Чампеон и Ник Финк представили доклад под названием "Инклюзивный веб-дизайн для будущего с прогрессивным улучшением". В начале доклада они обратились с призывом к оружию:

«Веб-дизайн должен созреть и принять развитие последних нескольких лет, отказаться от отчужденного отношения, сформировавшегося в эпоху грубости и беспорядка доткомов, осознать грядущее будущее широкого разнообразия устройств и платформ и отделить семантическую разметку от логики представления и поведения.»

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

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

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

Чтобы подчеркнуть это, дизайнер Дэн Седерхолм создал веб-сайт, чтобы ответить на вопрос: "Должны ли веб-сайты выглядеть одинаково в каждом браузере?". Ответ на этот вопрос вы можете найти по адресу URL:

dowebsitesneedtolookexactlythesameineverybrowser.com

Рискуя испортить вам сюрприз, ответом будет громкое "Нет!". Если вы посетите этот сайт, вы увидите этот ответ, гордо вывешенный на экране. Но в зависимости от возможностей вашего браузера, вы можете увидеть или не увидеть некоторые стилистические изыски, примененные к этому однословному ответу. Даже если вы не увидите никаких стилей, вы все равно получите содержимое, размеченное с помощью семантического HTML.

Cut the Mustard (

Разрезание

горчицы

)

Разделение структуры и представления относительно простое. Вы можете объявлять любые стили, какие захотите, будучи уверенными в том, что браузеры проигнорируют то, что им непонятно. Разделить структуру и поведение не так просто. Если вы дадите браузеру JavaScript, который он не понимает, он не только не применит желаемое поведение, но и откажется разбирать остальную часть JavaScript.

Прежде чем использовать ту или иную функцию JavaScript, стоит проверить, поддерживается ли она. Такое обнаружение функции может уберечь посетителей вашего сайта от проблем из-за неподдерживаемой функции. Если вы хотите использовать Ajax, сначала проверьте, поддерживает ли браузер объект, который вы собираетесь использовать для включения этой функции Ajax. Если вы хотите использовать API геолокации, сначала проверьте, поддерживает ли его браузер.

Команда веб-разработчиков, работающая над новостным сайтом BBC, назвала этот вид обнаружения функций " разрезание горчицы". Браузеры, которые отрезают горчицу, получают улучшенный опыт. Браузеры, которые не отрезают горчицу, по-прежнему получают доступ к контенту, но без улучшений JavaScript.

Обнаружение особенностей, отрезание горчицы, как бы вы это ни называли, является довольно простой техникой. Допустим, вы хотите обойти DOM с помощью querySelector и прикрепить события к некоторым узлам в документе с помощью addEventListener. Ваша логика разрезания горчицы может выглядеть примерно так:

if (document.querySelector && window.addEventListener) {

// Enhance!

}

Здесь следует отметить два момента:

Это определение функции, а не браузера. Вместо того чтобы спрашивать "какой у вас браузер?" и пытаться сделать вывод о поддержке функции из ответа, безопаснее просто спросить "поддерживаете ли вы эту функцию?".

Другого утверждения не существует.

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

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

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

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

«Существует разница между поддержкой и оптимизацией.»

Поддерживайте все браузеры … но не оптимизируйте все.

Некоторые дизайнеры неправильно понимают прогрессивное улучшение, считая, что все функциональные возможности должны быть предоставлены каждому. На самом деле все наоборот. Прогрессивное улучшение означает предоставление основной функциональности для всех. После этого каждый браузер сам за себя. Прогрессивное улучшение не ограничивает возможности использования функций, а предоставляет веб-дизайнерам возможность безопасно использовать новейшие и лучшие функции, не беспокоясь о старых браузерах. Скотт Джел из агентства Filament Group выразил это кратко:

«Прогрессивное улучшение позволяет нам сосредоточиться на затратах на создание функций для современных браузеров, не беспокоясь о том, что мы кого-то оставим без внимания. При наличии квалифицированной кодовой базы поддержка старых браузеров предоставляется почти бесплатно.»

Если сайт создан с использованием прогрессивного улучшения, то ничего страшного, если какая-то функция не поддерживается или не загружается: Ajax, геолокация, что угодно. До тех пор, пока основная функциональность остается доступной, веб-дизайнерам не нужно изгибаться, пытаясь впихнуть поддержку новых функций в старые браузеры.

Вы также получаете сайт, более устойчивый к модели обработки ошибок JavaScript. Мат Маркиз работал вместе со Скоттом Джелом над отзывчивым веб-сайтом для газеты Boston Globe. Он отметил:

«Множество классных функций в Boston Globe не работают, когда JS ломается; "чтение новостей" – не одна из них.»

Inclusive Web Design For the Future with Progressive Enhancement by Steven Champeon and Nick Finck

Do websites need to look exactly the same in every browser? by Dan Cederholm

Support vs Optimization by Brad Frost

The Pastry Box by Scott Jehl

Допустим, вы поставщик новостей. Это и есть основная функциональность – предоставлять новости. Есть много, много других услуг, которые вы также можете предоставить; интерактивные головоломки, уведомления в реальном времени и многое другое. Какими бы ценными ни были эти услуги, они, вероятно, не так важны, как обеспечение доступа людей к новостям.

Подборка новостных изданий.

Когда основная функциональность определена, пора переходить ко второму шагу: как сделать эту основную функциональность доступной с помощью максимально простой технологии?

Теоретически, простой текстовый файл был бы самым простым возможным способом предоставления новостей. Но поскольку мы говорим именно о веб-технологиях, давайте сделаем оговорку: как сделать основную функциональность доступной с помощью максимально простой веб-технологии? Это может быть HTML-файл, передаваемый по URL.

Даже на этой ранней стадии можно все переусложнить. HTML может быть излишне раздутым. URL может быть излишне многословным; его трудно передать или запомнить.

Теперь, когда новости были размечены с помощью соответствующих элементов HTML – статей, заголовков, абзацев, списков и изображений – пришло время для третьего шага: улучшить!

По умолчанию новости будут представлены с использованием собственной таблицы стилей браузера. Это разборчиво, но не совсем приятно. Применив собственный CSS, вы можете придать содержимому более приятную форму. В вашем распоряжении пробелы, выравнивание, цвет и контраст. Вы даже можете использовать пользовательские шрифты – улучшение, которое было невозможно в Интернете в течение многих лет.

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

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

Благодаря постоянно развивающейся природе CSS, существует множество способов применения макета. Как сказал Энди Таненбаум:

«Самое приятное в стандартах то, что у вас есть из чего выбрать..»

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

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

Вот лишь некоторые из социальных сетей, которые появились в Интернете.

Отображать сообщения в веб-браузере несложно. На сервере может быть много сложностей, связанных с базами данных, синхронизацией, очередями и балансировкой нагрузки, но HTML, необходимый для структурирования списка в обратном хронологическом порядке, не сильно отличается от HTML, необходимого для новостного сайта.

Для отправки сообщения из браузера на веб-сервер требуется интерактивный HTML. Вот тут-то и приходят на помощь формы. В этом случае формы с текстовым вводом и кнопкой отправки должно быть достаточно, по крайней мере, для базового функционала.

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

Если бы мы оставили сайт в таком состоянии, только на HTML, я не думаю, что мы скоро отпраздновали бы выход нашей компании на IPO. Чтобы действительно выделить наш сервис на фоне конкурентов, нам необходим третий шаг в этом процессе: улучшение!

По крайней мере, мы можем применить ту же логику, которую мы использовали для новостного сайта, и стилизовать наш сервис. Используя CSS, мы можем обеспечить цвет, текстуру, контраст, веб-шрифты, а для больших экранов – макет. Но давайте не будем останавливаться на презентации. Давайте улучшим и взаимодействие.

В настоящее время эта социальная сеть имеет такой же тип взаимодействия на основе страниц, как и новостной сайт. Каждый раз, когда кто-то отправляет сообщение на сервер, сервер отсылает браузеру новую страницу. Мы можем сделать лучше. Пришло время для Ajax.

Мы можем перехватить отправку формы и отправить данные на сервер с помощью Ajax – мне нравится использовать слово Hijax для описания такого перехвата Ajax. Если есть ответ от сервера, мы также можем обновить часть текущей страницы вместо обновления всей страницы. Также было бы неплохо представить подходящую анимацию.

Мы можем пойти дальше. Браузеры, поддерживающие WebSockets, могут получать сообщения с сервера. Люди, использующие эти браузеры, могли получать обновления, как только они были отправлены. Можно даже использовать одноранговые соединения между браузерами, чтобы люди могли общаться напрямую.

Не каждый браузер поддерживает эту расширенную функциональность. Это не страшно. Основная функциональность – отправка и получение сообщений – по-прежнему доступна всем.

Что, если бы наша социальная сеть была более специализированной? Давайте сделаем сервис для обмена фотографиями. Это немного поднимает планку. Вместо отправки и получения сообщений основной функцией теперь является отправка и получение изображений.

Сайты обмена фотографиями.

Интерфейс должен показывать обратный хронологический список изображений. HTML справится с этой задачей. И снова нам нужна форма для отправки данных на сервер, но на этот раз это должна быть загрузка файла, а не текстовое поле.

С этими изменениями основная функциональность создана. Настало время для усовершенствования.

Помимо всех существующих усовершенствований – CSS, веб-шрифтов, Ajax, WebSockets – мы можем использовать API File, представленный в HTML5. Это позволяет нам манипулировать изображением непосредственно в браузере. Мы можем применять эффекты к изображению перед отправкой его на сервер. Используя фильтры CSS, мы можем предложить целый ряд улучшений изображения – от оттенков сепии до виньеток. Но если браузер не поддерживает API File или фильтры CSS, люди все равно могут загружать свои селфи с лицами уток.

Было время, когда использование программного обеспечения означало установку на компьютер отдельных программ. Сегодня можно иметь машину, на которой не установлено ничего, кроме веб-браузера. Написание электронных писем, поиск контактных данных, назначение встреч в календаре, ведение бухгалтерского учета и выполнение других финансовых задач – все это можно делать без установки специальных приложений. Вместо этого, зайдя по URL-адресу, можно вызвать нужный инструмент в нужный момент.

Поставка программного обеспечения через Интернет не просто заменяет способ работы, ориентированный на настольные компьютеры. Наличие подключения к Интернету открывает возможности для всех видов совместной работы. Возьмем, к примеру, приложения, которые когда-то назывались "текстовыми процессорами". Пока эти программы были привязаны к отдельным машинам, попытка совместного редактирования документа была сложной задачей, требующей много координации, пересылки файлов туда и обратно. При использовании Интернета, обмен одним URL-адресом может позволить нескольким людям работать над одним и тем же документом.

Инструменты совместного письма в Интернете.

Давайте применим трехэтапный процесс к текстовому процессору на базе Интернета:

«Определите основную функциональность.»

Тавтологическим ответом будет "обработка слов". Не очень полезно. Что люди на самом деле делают с этим программным обеспечением? Они пишут. Они делятся. Редактируют.

«Определите основную функциональность.»

Если посмотреть на наши три глагола – писать, делиться и редактировать – то один из них мы получаем бесплатно, просто используя URL: делиться. Два других – писать и редактировать – требуют использования формы. Базовый элемент TEXTAREA может служить вместилищем для слов, предложений и абзацев, из которых будет состоять все – от технических отчетов до великого американского романа. Отправка этого содержимого на веб-сервер означает, что его можно сохранить на потом.

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

«Улучшайте!»

Используя JavaScript, скромный TEXTAREA можно заменить более богатым интерфейсом редактирования, распознающим каждое нажатие клавиши и применяющим стилизацию на лету. Веб-шрифты могут сделать процесс написания более красивым. Ajax позволит сохранять работу на сервере практически постоянно, без необходимости отправки формы. Сокеты WebSockets позволяют нескольким людям одновременно работать над одним и тем же документом.

Для работы Ajax и WebSockets требуется подключение к Интернету. Гарантии стабильного интернет-соединения нет, особенно если вы пытаетесь работать в поезде или в гостинице. Современные браузеры предоставляют функции, которые после первоначальной загрузки страницы могут превратить саму сеть в улучшение.

Если браузер поддерживает какую-либо форму локального хранения, то данные могут храниться в базе данных на стороне клиента. Нестабильные сетевые соединения или неожиданное отключение электричества не помешают сохранить важный документ. Используя Service Workers, веб-разработчики могут предоставить инструкции о том, что делать, когда браузер (или сервер) находится в автономном режиме.

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

Уорд Каннингем, создатель вики, придумал термин "технический долг", чтобы описать общую проблему в мире программного обеспечения. Решения, принятые в спешке в начале проекта, приводят к каскаду проблем в дальнейшем. Мне нравится думать о трехэтапном многоуровневом подходе как о своего рода "техническом кредите". Уделив время обеспечению основной функциональности в начале, вы получаете свободу для экспериментов в дальнейшем.

Некоторые люди неправильно понимают прогрессивное улучшение как отказ от новейших и лучших браузерных технологий, но на самом деле все наоборот. Многоуровневый подход к созданию веб-страниц дает вам разрешение попробовать новейшие API JavaScript, независимо от того, как много или мало браузеров в настоящее время их используют.

Мы рассмотрели несколько примеров применения трехэтапного подхода к нескольким продуктам и услугам – новостям, социальным сетям, обмену фотографиями и обработке текстов. Вы можете применить этот подход ко многим другим услугам: внесение и обновление пунктов в список дел, управление встречами в календаре, поиск маршрутов, бронирование столиков в ближайших ресторанах. Каждый из них может быть создан с помощью одного и того же процесса:

Определите основную функциональность.

Сделайте эту функциональность доступной, используя максимально простую технологию.

Улучшайте!

Этот подход работает в разных масштабах. Он работает не только на самом высоком уровне сервиса; его можно применять и на уровне отдельных URL-адресов.

Спросите "Какова основная функциональность этого URL?" сделать эту функциональность доступной с использованием простейшей технологии, а затем улучшить оттуда. Это может действительно прояснить, какой контент наиболее важен, что важно в мобильном первом реагирующем рабочем процессе. Как только вы это установите, убедитесь, что содержимое отправляется с сервера как HTML (простейшая возможная технология). Затем, используя условную загрузку, вы можете решить сделать запросы Ajax для поддержки контента, если экран недвижимости доступна. Для URL-адреса отдельной новостной истории, сама история будет отправлена в первоначальном ответе, но связанные с ней истории или комментарии могут быть перенесены с сервера только по мере необходимости (хотя вы все еще можете предоставить ссылки на соответствующие истории и комментарии для всех).

Мы можем пойти глубже. Мы можем применить трехэтапный процесс в масштабе отдельных компонентов на странице. "Какова основная функциональность этого компонента? Как я могу сделать эту функциональность доступной, используя максимально простую технологию? А теперь как я могу ее улучшить?"

Компонент может быть разработан как поющая и танцующая интерактивная карта. В рентгеновских очках основная функциональность оказывается гораздо проще: показать местоположение. Предоставьте адрес этого места в виде текста: простейшая возможная технология. Теперь вы можете улучшить.

Стоит помнить, что улучшения могут предоставляться по скользящей шкале. Первым улучшением для текстового адреса может быть статичное изображение. Следующим усовершенствованием может быть замена статичного изображения интерактивной "скользкой" картой, работающей на Ajax. Если браузер поддерживает API геолокации, можно показать расстояние до места. Добавьте анимацию и переходы, чтобы лучше передать направление.

Навигация сайта – еще один дискретный компонент, который хорошо поддается скользящей шкале улучшений. Основная функциональность навигации заключается в предоставлении ссылок на ресурсы. Самая простая и до сих пор лучшая технология для этого – скромная гиперссылка. Список ссылок – это то, что нужно. Теперь, когда все готово, вы можете усовершенствовать навигацию, сделав ее по-настоящему привлекательной. Навигация вне холста, прогрессивное раскрытие, скольжение, пролистывание, угасание, расширение… пределы неба безграничны.

Поскольку улучшения могут быть добавлены в соответствии с возможностями каждого браузера, быстро становится ясно, что этот подход не сводится к тому, чтобы иметь две версии всего (базовую версию и улучшенную версию). Вместо этого сервис, URL-адреса и компоненты, которые вы разрабатываете, могут быть восприняты любым количеством способов. И это нормально.

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

Designing With Progressive Enhancement by Filament Group

Когда проект Web Standards Project начал кампанию, призывающую дизайнеров перейти с таблиц для верстки на CSS, она встретила сопротивление. Их снова и снова критиковали за наивность. "Конечно, макет на основе CSS может подойти для простого персонального сайта, но он никак не может подойти для большого сложного проекта".

Затем Даг Боуман возглавил CSS-редизайн сайта Wired.com, а Майк Дэвидсон – CSS-редизайн сайта ESPN.com. После этого открылись шлюзы.

Когда Итан Маркотте продемонстрировал возможности отзывчивого дизайна, это встретило сопротивление. "Конечно, отзывчивый дизайн может подойти для простого персонального сайта, но он никак не может быть масштабирован для большого сложного проекта".

Затем газета Boston Globe запустила свой отзывчивый сайт. Microsoft сделала свою домашнюю страницу отзывчивой. Снова открылись шлюзы.

Сегодня похожая история. "Конечно, прогрессивное улучшение может сработать для простого персонального сайта, но оно никак не может подойти для большого сложного проекта".

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

Создание устойчивых веб-сайтов – сложная задача. Требуется время для продуманного многоуровневого применения функциональности и возможностей. В результате вы получаете сайт, который может лучше реагировать на неожиданные обстоятельства – необычные браузеры, нестабильные сетевые соединения, устаревшие устройства. Тем не менее, для многих веб-дизайнеров временные затраты кажутся слишком высокими.

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

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

В руководстве по проектированию государственной службы Великобритании приводится еще более краткая форма трехэтапного процесса, который я описал:

Во-первых, просто заставить его работать

Во-вторых, сделать так, чтобы работало лучше

Руководство по проектированию также объясняет, почему:

«Если вы создаете страницы с мыслью о том, что другие части, кроме HTML, являются необязательными, вы создадите более качественную и сильную веб-страницу.»

Гениальный ученый-компьютерщик Грейс Хоппер хранила на стене необычные часы. Они шли против часовой стрелки. Когда ее спросили об этом, она ответила, что это произвольная конвенция, сказав:

«У людей аллергия на перемены. Они любят говорить: "Мы всегда делали это так". Я стараюсь бороться с этим. Вот почему у меня на стене висят часы, которые идут против часовой стрелки.»

Коммодор Грейс М. Хоппер, ВМС США.

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

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

По этой же причине вы можете начать применять этот многоуровневый подход без необходимости убеждать своих коллег, начальника или клиентов. Если им все равно, то они и не заметят. Как сказала Грейс Хоппер, "легче попросить прощения, чем получить разрешение".

Изменение рабочего процесса или процесса может быть особенно сложным, если он вступает в противоречие с используемыми инструментами. Инструмент должен помогать людям выполнять свою работу более эффективно. Инструмент должен быть подчинен рабочему процессу. Слишком часто вместо этого инструменты диктуют предпочтительный способ работы. Будь то редакторы WYSIWYG, программы графического дизайна, системы управления контентом или фреймворки JavaScript, инструменты неизбежно влияют на рабочие процессы.

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

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

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

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

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

В сентябре 2011 года я выступал на конференции в Теннесси вместе с несколькими людьми, которые были намного умнее меня. После завершения официального мероприятия мы отправились за город, где сняли дом на несколько дней. Мы собрались вместе, чтобы попытаться понять, куда движется Интернет.

Небольшая выборка устройств с выходом в Интернет.

Мы были, честно говоря, напуганы. Распространение мобильных устройств изменило все. Планшеты были на подъеме. Люди говорили об интернет-телевизорах. Мы надеялись понять, что будет следующей большой вещью. Может быть, холодильники с поддержкой Интернета?

В конце концов, единственное, в чем мы могли быть уверены, – это в неопределенности:

«Процесс разрушения будет только ускоряться. Количество и разнообразие подключенных устройств – многие из которых мы еще не представляли – будет расти, как и количество и разнообразие людей по всему миру, которые их используют..»

Это не повод для отчаяния, это повод для радости. Мы могли либо бороться с этим будущим, либо принять его. Понимая, что невозможно быть защищенными от будущего, мы решили быть дружелюбными к будущему:

Признавайте и принимайте непредсказуемость.

Думайте и ведите себя с учетом будущего.

Помогайте другим делать то же самое.

Этот первый шаг является самым важным: признание и принятие непредсказуемости. Именно это является движущей силой жизнестойкого веб-дизайна. Лучший способ быть ориентированным на будущее – это быть обратно совместимым.

             Символ дружбы с будущим.

Я хотел бы предсказать будущее. Единственное, что я могу предсказать наверняка, – это то, что все изменится.

Я не знаю, какие устройства люди будут использовать в Интернете. Я не знаю, какое программное обеспечение люди будут использовать в Интернете.

Будущее, как и веб, неизвестно.

Будущее, как и Интернет, будет написано вами.

Government Service Design Manual

Future Friendly