Предыстория
В 2013 году я создавал интерфейс адаптивного веб-приложения, в котором было много данных для отображения. Я сделал много адаптивного дизайна, используя запросы @media , но, поскольку я пытался повторно использовать компоненты из одного макета в другом макете, я хотел, чтобы мои отзывчивые контрольные точки соответствовали ширине элементов вместо ширины. браузера.
Это то, что CSS в настоящее время не может сделать, поэтому я копировал и вставлял множество стилей из шаблона в шаблон, меняя в основном только точки останова. Я искал существующие обходные пути, в основном инструменты и плагины JavaScript, чтобы помочь мне автоматизировать этот процесс или вывести для меня дублированный код — но все это казалось несовершенным решением проблемы.
Я слышал о Less , препроцессоре CSS, который позволяет вам создавать CSS, который включает дополнительные функции, такие как переменные и функции, которые не являются частью стандартного CSS. Вы можете добавить небольшой плагин JavaScript на свой веб-сайт, который позволит браузеру читать этот нестандартный CSS, и весь ваш нестандартный код волшебным образом преобразуется в стили, понятные браузеру. Я начал задумываться, можно ли таким же образом расширить CSS, чтобы решить мою проблему!
Рождение плагина
Где-то по пути мои пути пересеклись с удивительным и креативным кодером по имени Максим. Я был большим поклонником некоторых прошлых проектов Максима , и у него были знания и понимание CSS и JavaScript далеко за пределами моего. Однажды, когда я думал о своих проблемах с CSS, я отправил ему следующее сообщение:
Мне нужен способ написания стилей CSS, который позволяет мне:
- указать разные стили в зависимости от текущей ширины элемента
- указать разные стили в зависимости от текущей высоты элемента
- держать элемент вертикально по центру в его родительском элементе все время
- держать элемент горизонтально по центру в его родительском элементе все время
- указать разные стили в зависимости от длины текста элемента
- указать разные стили в зависимости от количества дочерних элементов, содержащихся в элементе
- Бонус: чтобы я мог перемещаться вверх по DOM с помощью
<селектораЕсли бы у меня была такая библиотека, я думаю, я мог бы разработать макеты, которые были бы по-настоящему пуленепробиваемыми и не ломаемыми. Мне нужны запросы
@element!Можно ли написать эти стили способом, который выглядит знакомым для людей, которые пишут CSS, но читаются и исполняются с помощью JavaScript?
Может ли JavaScript анализировать текст (
.jssфайл.jssили<script type="text/jss">где я могу писать блоки CSS, но обернуть их специальными запросами@element, которые могут быть прочитаны JavaScript, и получить вычисленные стили, примененные к странице?@element('.widget-box', min-height: 500px) { .widget-box { background: red; } .widget-box a { font-size: 18pt; } }или
@element('#username', min-length: 20) { #username { font-size: 8pt; } #username < label { border: 1px solid red; } }Для того, чтобы это было действительно полезно, нужно иметь небольшую кривую обучения для людей, которые уже знают CSS, но не знают JavaScript. Они должны иметь возможность добавить библиотеку JavaScript на сайт и написать собственные стили, чтобы она работала без какого-либо специального JavaScript. Я думаю, это делает это больше похожим на полифилл, чем на плагин 🙂
Возможно ли что-то подобное?
— Томми, 5 декабря 2014 г.
Я не был уверен, какой ответ я получу. Я уже пытался создать несколько плагинов самостоятельно без особого успеха. Будучи новичком в JavaScript, я был очень ограничен в том, что я мог построить самостоятельно, и все решения, которые я пытался создать самостоятельно, заканчивались добавлением дополнительной работы. Чтобы решение было действительно ценным, оно должно снизить общую нагрузку и упростить его разработку — оно должно удалять ограничения , а не добавлять их!
Быстро я получил ответ от Максима:
Ответ на все ваши вопросы — да. Это возможно. 🙂
Я не вижу ни одной миссии в вашем описании, а три:
Вы хотите расширить возможности CSS, чтобы делать то, что медиа-запросы еще не делают: применить некоторый стиль к элементу в зависимости от его размера или длины его текстового содержимого.
Вы хотите расширить селекторы CSS, чтобы добавить родительский селектор.
Вы хотите расширить обычные свойства CSS, связанные с потоком, добавив способ вертикального выравнивания чего-либо во что-либо. Это 3 священных грааля CSS, вы устанавливаете планку очень высоко: D
— Максим, 5 декабря 2014 г.
В последующие недели по электронной почте между Канадой, Францией и Соединенными Штатами мы с Максимом выяснили, как будет выглядеть этот новый синтаксис. Мы написали и поделились кодом на языке, которого еще не было, поговорили о потенциальных проблемах и обходных путях, и, в конце концов, он создал первую версию плагина EQCSS JavaScript в соответствии с тем, что, как мне казалось, мне было нужно.
Очень скоро я смог использовать этот плагин на веб-сайтах, над которыми я работал, и к январю 2015 года он впервые был использован в производстве. Мы продолжали экспериментировать с ним, добавляя новые функции и улучшая поддержку и производительность в течение следующих месяцев. Поскольку плагин был изначально написан, я выучил достаточно JavaScript, чтобы иметь возможность устранять неполадки, ремонтировать, обслуживать и даже добавлять собственные новые функции.
Почему я построил плагин
Когда я думаю о причинах, почему я потратил столько времени и усилий на создание такого решения, я думаю, что было несколько разных мотивов. Во-первых, я хотел решить проблемы, с которыми я сталкивался в своей работе каждый день; что-то, что я мог бы использовать немедленно, чтобы сэкономить время с первого дня, когда я использовал это.
Другой мотивацией было выяснить, насколько податлива сеть как платформа. Можно ли было изменить и расширить один из основополагающих языков Интернета (CSS) и добавить в него новые функции? Как далеко вы могли бы взять это?
Первоначально этих причин было достаточно, чтобы я начал, но теперь, когда у нас есть решение, которое хорошо конкурирует с другими решениями, есть и дополнительная мотивация: можем ли мы усовершенствовать наше решение и представить более стандартизированный метод для решения подобных проблем, чтобы каждый мог получить пользу ?
Проблемы создания плагина
При создании этого проекта я столкнулся с рядом проблем. Кто-то с самим синтаксисом, кто-то с написанием плагина, кто-то с поддержкой различных браузеров по мере того, как они меняют функции, а кто-то на людях, помогая людям понять концепции и максимально использовать возможности плагина.
Синтаксические проблемы
Некоторые из проблем синтаксиса, с которыми мы сталкивались, пытались ограничить весь синтаксис только одним языком: CSS. Мы не хотели, чтобы пользователь добавлял что-то дополнительное в свою HTML-разметку для кода, который они пишут на своем CSS, чтобы работать, и мы хотели избежать того, чтобы пользователю приходилось самостоятельно писать собственный JavaScript-код для начала работы.
Еще одна проблема заключалась в том, чтобы разработать синтаксис, который был бы достаточно выразительным, чтобы обрабатывать сценарии использования, которые нам необходимо было поддерживать сразу, при этом обеспечивая достаточную гибкость, чтобы позволить пользователям писать свои собственные дополнительные функции по мере необходимости. Эта дополнительная гибкость была полезна для нас при тестировании и добавлении новых функций, поскольку создание прототипа можно путем написания собственного кода с помощью плагина таким образом, который будет тесно связан с кодом, который необходимо добавить в плагин для его расширения. Плагин можно использовать для создания прототипа новых функций для себя, и поскольку мы ввели эту дополнительную гибкость, скорость, с которой мы смогли добавлять новые функции, увеличилась.
При изобретении любой новой языковой функции, как мы делали с CSS, важно спроектировать ваш синтаксис таким образом, чтобы он был ориентирован на будущее, если в будущем к языку будут добавлены функции с аналогичными именами, которые будут работать не так, как ваша реализация. , С нашим плагином пользовательский синтаксис может быть прочитан из CSS, но синтаксис также может быть загружен непосредственно из плагина как отдельный тип скрипта, который браузер не будет пытаться читать как CSS. Из-за этого пользовательского типа сценария новые термины в нашем синтаксисе могут сосуществовать в одной и той же кодовой базе вместе с другими языками, которые включают аналогичные термины, и при этом они не конфликтуют.
Проблемы с плагином
Одна из наших целей при попытке создать плагин (то, чего я никогда раньше не делал в таком масштабе) заключалась в том, чтобы мы хотели, чтобы размер файла был достаточно небольшим, а исходный код был достаточно простым, чтобы каждый мог читать, редактировать и расширять плагин. для их нужд. Для меня также было важно, чтобы функции, которые мы добавили, работали в Internet Explorer 8. Объем необходимого для IE8 кода в конечном итоге составлял большую часть общей кодовой базы, но мы смогли структурировать плагин таким образом, чтобы все кода, специфичного для IE8, можно поместить в отдельный файл. Этот дополнительный файл должен быть включен только в проекты, где требуется поддержка IE8, и его можно безопасно пропустить в проектах, где поддержка IE8 не требуется.
Проблемы браузера
При разработке плагина, который должен работать в веб-браузерах, вы начинаете рассматривать веб-браузеры как движущиеся цели. Мы изначально создали и протестировали плагин в Chrome, Safari, Firefox и Internet Explorer, и сначала это были устаревшие версии Internet Explorer, которые налагали самые строгие ограничения на плагин. Но в начале 2016 года, после того как плагин находился в эксплуатации в течение года, мы получили сообщение об ошибке, согласно которому в новых версиях Firefox некоторые страницы с плагином испытывали серьезную проблему с производительностью! Мы ничего не изменили в нашем коде — но после изучения различных выпусков Firefox для этой ошибки, казалось, что что-то изменилось в том, как Firefox думал о событии прокрутки страницы, и это вызывало пересчеты в нашем плагине намного больше, чем это было необходимо ,
Предложенное решение для исправления Firefox заключалось в добавлении механизма отладки к нашему плагину — куска кода, который мог бы установить верхний предел частоты, с которой можно было бы запрашивать пересчет. Это решило бы нашу проблему в Firefox, но таким образом, что это повлияло на работу плагина во всех браузерах, потенциально открывая непредвиденные проблемы. Что еще хуже, при тестировании решений в предварительных версиях Firefox проблема, по-видимому, отсутствовала в версиях Firefox, которые были через несколько месяцев после выпуска. Было страшно знать, что другие люди используют наш плагин, и что, если мы не выпустим патч, пользователи Firefox по всему миру увидят ухудшенный опыт в течение нескольких месяцев. В итоге, после многих испытаний, мы выпустили патч, добавляющий механизм отладки, исправляющий ошибку для пользователей Firefox и повышающий производительность в других браузерах.
Модульные испытания
Первоначально мы создали плагин для работы как полифилл (или прокладка). Он был разработан для запуска непосредственно в браузере, что облегчало размещение на CDN. Вскоре мы начали получать запросы от пользователей Webpack, которые строили проекты с использованием модулей JavaScript и хотели, чтобы версия плагина была упакована как таковая. К счастью, мы смогли обернуть существующий плагин кодом из шаблона модуля UMD, который превратил его в модуль. Плагин теперь может быть загружен загрузчиками модулей, такими как Webpack и Browserify. Как и раньше, если вы загружаете плагин вне загрузчика модулей (например, связываетесь с файлом прямо в браузере), плагин все равно присоединяется к глобальному объекту (браузеру) так же, как и раньше, и работает нормально.
Проблемы с документацией
Последняя область, которая была проблемой при создании нового плагина, — это поиск (или создание) словаря, который позволяет вам рассказать о том, как работают эти новые концепции и как другие могут извлечь выгоду из этих идей в своих проектах. Со временем, благодаря общению с другими, написанию спецификации, документации и многих статей, этот пробел устраняется, но любой плагин, имеющий дело с новой технологией или концепцией, с самого начала столкнется с подобным пробелом в коммуникации.
Почему вы должны делать то же самое?
После моего опыта создания плагинов я больше, чем когда-либо, с энтузиазмом делаю одно и то же! Это похоже на магию — делать то, что вы считали невозможным, и очень приятно испытывать реакцию разработчиков, которые сталкиваются с такими же проблемами в тот момент, когда они понимают, как их проблемы могут быть наконец решены.
Обмен вашими решениями с сообществом — это беспроигрышная ситуация.
- Всем выгодно читать ваш код и использовать ваши методы в своей работе
- Вы получаете выгоду, имея стандартизированную ссылку для начала в будущем
- Часто другие люди будут предлагать функции и сообщать о случаях, которые вы пропустили, которые помогут вам улучшить ваше решение.
Там нет недостатков! Если у вас есть решение, если это такая языковая функция, как у меня, вы можете двигаться дальше, написав спецификацию для новой функции и начать предлагать ее включение в стандарт для этого языка.
Другие вещи, которыми вы можете заняться, когда у вас есть плагин, — это способы использовать это решение для исследования новых идей или концепций или использования вашего плагина в качестве плацдарма для дальнейших экспериментов с плагином. С момента создания моего плагина для решения моей основной потребности в элементных запросах я смог использовать возросшую мощность и гибкость EQCSS для исследования и экспериментов с решениями CSS и в других областях. Я провел эксперименты с такими вещами, как соотношения сторон (то, что в CSS в настоящее время не имеет свойств) и способами расширения селектора атрибутов в CSS, а также множеством других идей.
Из этих экспериментов создаются новые плагины , и мы надеемся, что они также могут быть использованы для изучения и открытия еще большего количества идей.
Мое единственное сожаление
После этого преображающего опыта единственное, что жалит на всех, это осознание того, что каждая функция, которую мы получили, работая в самых современных браузерах, была тем, что мы также заставили работать в IE8. Это означает, что за все годы, прошедшие с момента выхода IE8, можно было делать все это , но пока пара разработчиков с открытым исходным кодом не сотрудничала и не потратила несколько недель на создание плагина, этого не было сделано.
Если у меня есть сожаление по поводу всего этого процесса, так это то, что идея возникла не раньше! Мы могли бы создавать сайты таким образом уже много лет, если бы кто-то попытался создать плагин, подобный этому много лет назад.
С нетерпением
Так что это значит для прямо сейчас ? Какие решения уже возможны сегодня и не требуют большой работы для реализации, но просто еще не существуют? Если у вас есть идея найти решение для чего-то, имеет смысл изучить его и попробовать построить его раньше, а не позже!
Весь мой взгляд на веб-разработку изменился после этого опыта, и именно такое чувство заставляет вас выпрыгивать из постели по утрам, чувствуя себя взволнованным вещами, которые вы можете создать к тому времени, когда вы ложитесь спать, которые в настоящее время не существуют правильно сейчас.
Поэтому я спрошу вас: с какими проблемами вы сталкиваетесь и какие у вас есть идеи по их решению?