Как мне написать HTML, CSS и JavaScript, чтобы облегчить работу бэкэнд-разработчиков?

Когда я получаю дизайн от дизайнера, я получаю его в виде файла PSD (Photoshop). Я всегда ожидаю правильных имен слоев и папок, в основном чистый и управляемый PSD. Исходя из этого, я разрабатываю HTML, CSS и JavaScript и доставляю его разработчикам. Чтобы им было легче понять, я

• написать семантический код,
• сохранить JavaScript и CSS во внешних файлах,
• добавлять полезные комментарии в файлах HTML, CSS и JS,
• использовать CSS-спрайты (хотя разработчикам это не нравится),
• использовать HTML5 котельную плиту,
• использовать jQuery для JavaScript,
• старайтесь использовать новые теги HTML5 и CSS3, когда это возможно, и
• отправил Zip-файл, содержащий HTML, CSS, JS и изображения.

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

Я хотел бы услышать от разработчиков и других ниндзя CSS, что еще можно сделать с точки зрения организации файлов и разметки, чтобы упростить интеграцию с внутренними системами (например, фоновые технологии, PHP, .NET). , Ruby и т. Д.) Разные клиенты используют разные системы.

Многие из этих ответов будут охватывать широкий спектр идей, но вот мои личные:

• Оставьте место в дизайне формы для сообщений об ошибках.
• Не помещайте ярлыки в поля ввода!
• Поместите свой CSS и JavaScript в отдельный файл, если вы не знаете, что делаете, и не чувствуете себя плохо по этому поводу.
• Сохраняйте элементы дизайна одинаковыми между страницами. Это бесит, когда компонент дизайна (например, «недавно просмотренный» блок) имеет разную разметку на каждой странице.
• Не делай то, что легко для тебя, делай то, что правильно. <button>Теги отстой. backround-imageдля вещей, которые на самом деле должны быть <img>тегами отстой.
• Убедитесь, что если вы создаете компонент страницы, он может масштабироваться. Я знаю, что большинство хороших разработчиков интерфейсов делают это, но у меня было много случаев, когда кто-то использовал одно изображение в ситуации с верхним / нижним колпачком. Программисты не любят открывать Photoshop.
• Проверьте ваши шаблоны. Программисты (хорошие) - преданные, детально ориентированные люди. Если они начнут видеть проблемы в вашем дизайне (возможно, в навигации нижнего колонтитула есть орфографические ошибки или несовместимые орфографические слова), это заставит их задавать вопросы и замедлять их работу.

Наконец, и, возможно, самое главное:

• Изучите основные соглашения языка, который разрабатывается в фоновом режиме. Возможность взглянуть на шаблон PHP и понять основной синтаксис оператора a foreachили, ifа также то, как отформатировать echoоператор или переместить <?php ?>тег, значительно повысит вашу ценность как внешнего разработчика - мне нравится, когда нужен внешний интерфейсный разработчик сделать простое изменение и может сделать это в шаблоне вместо того, чтобы вручить мне новый почтовый индекс всех своих файлов.
• В качестве приложения, научитесь использовать программное обеспечение для контроля версий. Вам не нужно быть экспертом, но если я смогу посмотреть на разницу, вместо того, чтобы пытаться выяснить, что изменилось между двумя zip-файлами, это упростит мою работу в сто раз.

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

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

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

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

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

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

CSS спрайты, которые вы цитировали, являются хорошим примером. Я не понимаю, как кто-то может создать веб-сайт, когда масштабируемость и производительность имеют значение, и на каждой странице есть ссылки на 100 изображений, 5 файлов CSS и 15 файлов JavaScript. С другой стороны, CSS-спрайты нелегко поддерживать, и небольшие изменения в дизайне могут потребовать много работы.

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

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

Это точно то же самое для CDN. Вы должны использовать его для больших сайтов, но вносить изменения будет сложнее. Например, если вы изменили файл CSS, вы должны заставить браузеры загрузить новый, изменив URI файла cdn.example.com/g.css?r=2, затем cdn.example.com/g.css?r=3и т. Д.

Кроме того, «легче» является относительным . См., Например, рекомендации по написанию CSS-кода: лично я предпочитаю один стиль на строку без пробелов:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

в то время как большинство людей ненавидят этот синтаксис и предпочитают тот, который я ненавижу и который трудно читать (нет, я не сумасшедший):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

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

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

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

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

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

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

Например, если у вас есть раскрывающийся список, JS гораздо меньше работает, чтобы привязать перетаскиваемый компонент с абсолютным позиционированием в контейнере с относительным набором (без координат), чем вытащить молот JQuery и получить координаты для его наведения. над элементом и просто вставьте его на место. Это также намного менее вероятно, чтобы сломаться в случаях, когда страница сдвигается или какая-то новая функция браузера выбрасывает информацию о позиционировании. Чем больше вы полагаетесь на навыки HTML / CSS, чтобы избежать работы JS, тем более надежным будет ваш пользовательский интерфейс.

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

Предпочитайте делегирование событий в контейнерах пользовательского интерфейса назначению слушателей непосредственно узлам конечной точки, таким как кнопки. Этот компонент пользовательского интерфейса теперь может работать со статическим HTML, но вы никогда не знаете, когда кто-то захочет иметь возможность извлечь и переписать HTML-код внутри с помощью innerHTML или чего-то еще. Если контейнер не поврежден и все события делегированы (см. Метод jquery 'on'), вам не нужно об этом беспокоиться, и они могут никогда не научиться трудному способу, которым замена HTML нарушает работу слушателей.

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

Что касается макета, сохраняйте HTML минимальным, семантическим и избегайте div-оболочек. Чем меньше HTML, тем проще проблемы с версткой для диагностики новичков.

Используйте понятные имена классов для утилиты CSS. Класс row может быть более понятным для нубов CSS, чем clearfix.

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

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

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

Как и все вещи, связанные с развитием, предпочитают СУХОЙ и минимализм

Это по-прежнему не позволяет мне просто комментировать (так глупо), но в качестве личной заметки, я бы сказал, я работаю спина к спине с PHP-кодером каждый день (а также помогаю в его работе), и самый простой инструмент, который мы нашли, это использовать набор инструментов Komodo и перечислять «переданные» переменные каждого вида / контроллера / модели в наборе инструментов, так что в любое время, если я собираюсь создать страницу вокруг набора данных, отправляемых на эту страницу, я можете посмотреть на панели инструментов и увидеть, какие именно данные отправляются и в каком «виде» они отправляются, а также наоборот с его стороны. Просто подсказка.