ставьте, только если у вас адаптивная верстка. Эта настройка пытается сохранить масштаб шрифта, но уменьшить ширину колонки до ширины экрана браузера.
<meta name="viewport" content="width=1024">
ставьте, если у вас сайт фиксированной ширины или резина с минимальной шириной. В этом случае сайт уменьшится в масштабе, чтобы колонка шириной 1024px помещалась без горизонтальной прокрутки.
Я бы ничего не делал с этой кнопкой. Она маленькая, не выпрыгивает, не мельтешит. Если крестик ставить, то тут вопрос: закрывать и сохранять состояние в куки или local storage (но тогда кнопка скроется почти навсегда) или закрывать до перезагрузки страницы (но тогда посетитель закрывает ее, а она появляется на каждой новой странице).
Я на фрилансе не работаю, так что выскажусь «чисто теоретически».
Мне больше всего нравится вариант с предварительной поэтапной оплатой. Потому что:
1) самый безопасный вариант для клиента и исполнителя. Если кому-либо из сторон не понравилось сотрудничество, доводим этап до конца и расстаемся. У клиента остаются результаты первого этапа, у исполнителя деньги.
2) страховка от неправильно выбранной цели. Если клиент в начале сам не знает, чего хочет, то в процессе работы, скорее всего, будет метаться и менять техзадание, пока ему не придет правильное понимание цели. Поэтапная оплата его отрезвляет: за каждое изменение надо платить, «хотелки» и «доделки» не бесплатны, иногда придется переделать этап целиком. Не получится бесконечно эксплуатировать исполнителя в рамках договора. И для клиента снижается риск оплатить весь сайт и получить не то, что на самом деле нужно было.
3) психологические преимущества и контроль. Исполнителя длинные проекты выматывают, проект надоедает и снижается качество работы. Короткие этапы воспринимаются легче и среднее качество работы выше. На маленьком таске проще приблизиться к идеалу. Для заказчика дедлайны — это способ убедиться, что все идет по плану.
Конечно, этапы должны быть не от балды назначены, а иметь конкретную конечную ценность и артефакты. Например:
1 этап — wireframes = кликабельный прототип. Нужен для того, чтобы исполнитель понял задачу именно так, как видит её заказчик. Заказчику тоже полезно визуализировать задачу, чтобы оценить её объем. Если исполнитель отвалится, заказчик с готовым пониманием задачи может идти к другому исполнителю.
и т.д.
2 этап — дизайн.
3 этап — чистовая верстка шаблонов.
4 этап — программирование бэкенда.
5 этап — наполнение контентом.
6 этап — тестирование и багфиксинг.
7 этап — запуск и поддержка.
если через админку нельзя вставить , то можно попробовать вставить юникодный неразрывный пробел (скопировать откуда-нибудь или вставить с помощью раскладки Бирмана ilyabirman.ru/projects/typography-layout )
Борис Якушев: я про то же самое и написал: когда контент хранится в файлах — их править можно и через FTP/SSH (но «вера» рекомендует использовать GIT и не лазить со своими правками на лайв-сайт).
А вот когда контент хранится в базе данных, ftp уже не поможет. Придется мучаться с textarea.
Юрий: согласен, генераторы статики не идеал, и не всякому проекту подойдут. С ними тоже хватает проблем: чем больше статей, тем дольше длится перегенерация, не всякую динамику можно запрограммировать через сторонние сервисы. Но основную ежедневную задачу — управление контентом — они хорошо решают.
Порог вхождения именно для редакторов контента, как раз таки, низкий: выучить Markdown (paulradzkov.com/2014/markdown_cheatsheet/) и пройти туториал по GIT (https://try.github.io/). Даже HTML знать не обязательно. Да и редактировать контент можно через GitHub и спец сервисы типа prose.io . Все остальные вопросы должны решать дизайнер и верстальщик.
А вот про скорость отдачи страниц — статик гены всё же быстрее. Причем быстрее сразу «из коробки». Только в случае полной оптимизации CMS догоняют статические сайты по скорости, но эту оптимизацию еще надо сделать (вспоминаю Joomla 3 года назад: по-умолчанию всё выключено, а когда включаешь — обнаруживаешь проблемы с инвалидацией кэша).
Делал сайты на Joomla с 2009 по 2013. Больше меня на нее добровольно не затянешь.
Тогда были проблемы с оптимизацией фронтенда: тяжело было сделать стабильный кэш + gzip; приходилось использовать Mootools и jQuery одновременно; некоторые компоненты тянули свой jQuery (и в итоге на фронтенде было 3-4 копии библиотеки, иногда разных версий); некоторые компоненты тянули свой Bootstrap от которого ломался шаблон. Шаблоны не всех компонентов можно было исправить, потому что компоненты не на MVC. А исправлять приходилось 40-60% шаблонов в чужих компонентах, чтобы подогнать под дизайн.
Вот такие у меня о ней воспоминания. А как там на Джумле сейчас?
Каждый решает исходя из своих целей, из аудитории и списка поддерживаемых браузеров.
Для меня есть смысл. Я отказался от понятия «кроссбраузерности», заменил его на «каждому браузеру по возможностям». Если браузер посетителя способен отрендерить красивую удобную верстку по новым технологиям, то нужно нужно осчастливить этих посетителей. Если у пользователя старый браузер, то показать ему верстку на фолбеке, и не ругать его за то, что у него недобраузер.
К тому же фолбек — это 20-40 строк кода на основные элементы модульной сетки. Не так уж и много.
Если элемент встречается ровно один раз — это не значит, что так будет всегда. Когда в верстке используется компонентный подход, при переделке структуры переписывать придется только HTML, т.к. CSS уже приспособлен для повторного использования.
Вы сейчас думаете как фрилансер, который делает маленькие корпоративные сайты на 10-20 страниц по утвержденным дизайнам и не заботится о том, что будет после него. А если переделывать, то сразу всё, чтобы больше заплатили. (Это я всё утрирую, извините, если обидел).
Когда работаешь с большим проектом, дизайнеры, верстальщики и бэкэнд программисты работают параллельно, а сверху им спускает требования бизнес-команда. Одна страница, пока дойдет до продакшена, может успеть поменяться 5 раз. Поэтому нужно думать наперед, «подстелить себе соломки», чтобы будущие возможные изменения занимали как можно меньше усилий.
Доводы против айдишников я вам озвучил. Если для вас они звучат не убедительно, значит вы еще наступите на эти грабли :) Успехов!
1. Айдишник можно использовать на странице один раз. Два и более раза — это уже не валидно. Поэтому, если понадобится переделать сайт по схеме «три колонки → блок от края до края → снова три колонки» на одной странице, этот кусок кода придется полностью переписывать.
2. На один элемент можно повесить только один айдишник, а классов на один элемент можно повесить много. Получается, если вешать стили на id, мы лишаемся гибкости.
3. У айдишников слишком высокий вес селектора. Если вам понадобится контекстно перестилить что-то внутри колонки, то вероятнее всего вы впишите в селектор айдишник и потом, чтобы обнулить овверрайд или сделать новый, вам придется использовать этот же айдишник (или поставить другой). Классами перебить селектор с айдишником не получится — не хватит веса. Айдишник будет множиться в css-ке и реффакторить становится всё сложнее.
Поэтому выводы: 1) никогда не вешать на айдишники стили; 2) если нет выбора, писать селектор так: div[id="left"] {...} — этот селектор медленнее, чем селектор по классу, но и вес у него на равне с классом. Т.е. это меньшее зло, чем айдишник в стилях.
