VZVZ: Я предлагаю завершить данное сравнение, т.к. каждый использует свои подходы в разработке. Участники самостоятельно с данного обсуждения выберут то, что им необходимо.
VZVZ: Да, как не странно звучит, но молодые бойцы на проектах постоянно забывают об этом. А наявность функц. и мод. тестирования зависит от проекта. Заказчики в основном на этом экономят деньги. В догонку еще вот прелести console: 1) alert() is blocking
2) alert() cannot be easily suppressed in non-debug environment
3) console typically formats your objects nicely and allows to traverse them
4) logging statements often have an interactive pointer to code which issued logging statement
5) you cannot look at more than one alert() message at a time
6) console s can have different logging levels with intuitive formatting
VZVZ алертами никто не дебажит, лучше использовать console.log, console.info, console.error и т.д. Алерты блокируют страницу. Подебажили Вы, забыли убрать алерты, залили на продакшен и... потерпают Ваши пользователи...
RushV: .menu > li { border-left: 1px solid #fff; } .menu > li:last-child { border-right: 1px solid #fff;} Чтобы понять как это работает, почитайте о комбинаторах и псевдоклассах в CSS
DTX: как минимум тем, что вы можете добавить целый скоп значений за один раз, а не писать $x[]=...; $x[]=...; Но для больших итераций в цикле array_push() проигрывает, с этим минусом согласен.
Единственный способ прочувствовать разницу, это начать их (фреймворки) изучать. Собственное мнение, основанное на опыте, всегда дороже, чем советы и обсуждения.
Ksider: можете изображение обвернуть в блок-враппер, над ним сделать такие же действия как и над изображением только залить коричневый цветом и сместить на толщину бордера вверх.
zlFast: можно это сделать с помощью css: для враппера, где находятся инпуты даете свойство display: table, для верхнего инпута display: table-footer-group, для нижнего - display: table-header-group.
Максим Тимофеев: точкой отсчета и будет Ваше ТЗ, в котором Вы определяете целевую аудитория для сайта, описываете какие разделы будут и т.д. А дело дизайнера создать на основе этого макеты.
weranda: передавайте тогда в URL ID базы клиентов, а на сервере по этому ID выполняйте необходимые действия. Пользователи будут видеть только ID в URL. Это если мы говорим о параметрах. Если говорить о php скрипте (экшене), то можно организовать редирект на другой экшен (в MVC фреймворках за это отвечают роуты).
Чем больше Вы знаете фреймворков и технологий, тем больше у Вас возможностей применять их и соответственно заработать. И это не означает, что Вы знаете хуже, чем другие. Если Вы знаете русский язык, то никто Вам не мешает выучить английский, французский и т.д. К тому же кто даст Вам гарантии, что Ваши знания и фреймворк не станет древним через пару лет?
xmoonlight, согласен с Вами, отличное решение. Теперь для Александр есть полностью алгоритм реализации. Хотя я бы не сохранял ID-устройства, только - ID-темы, функционал был бы проще как для разработчика, так и пользователя. Но это уже по выбору Александр.
Не вариант, т.к. LocalStorage хранит данные локально. Получится, что пользатель зайдет на сайт, например, с стационарного компа, выберет тему, а потом на мобильном у него опять же будет дефолтовая тема, пока он ее снова не сменит. Получается сколько устройств, столько раз и менять тему под себя. А если он инкогнито зайдет в браузер? Я считаю, что лучше это хранить в базе, как предлагает Сергей Сунцев
Web Lizard: Делаете подборку статей, которые подтверждают вашу правоту в том, что это невозможно сделать и предоставляете их заказчику. Желательно также указать заказчику варианты решения, например, как вы говорили, что можно залить изображением или отказаться от данного шрифта и подобрать такой, который выглядит адекватно. Также, чтобы перестраховаться, можете описать плюся и минусы данных вариантов. Поверьте мне, заказчик поменяет мвое мнение о шрифтах:)