Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Казалось бы, причем здесь jQuery UI.
Считаю что для создание прототипа css фреймворки — самое то. Сам проголосовал за Bootstrap.
Вопрос, как я понял, не про прототипы и фреймворки, а про верстку вообще и готовые сетки.
К сожалению, bootstrap так и не пользовал, но тоже проголосовал за него. Если буду делать frontend интерфейс — выбор уже сделан. Для backend использую ExtJS.
Проголосовал за Bootstrap. Огромным плюсом считаю то, что в нем возможна гибкая настройка параметров сетки. Так что достаточно просто попросить дизайнера делать макеты с сеткой, а дальше уже дело техники
Да как на войне, все допустимо, вопрос только в целесообразности. Я б рад использовать какие-то фреймворки для ускорения верстки, но никакого ускорения, даже в перспективе, не заметил.
Я считаю, что используя фреймворк разработчик безусловно должен понимать что он делает, а не просто лепить классы по примеру! Также использовать фрейм ворк только в том случае если дизайнер рисовал для дизайн четко по требованиям фреймворка! Если дизайн райндомный то все отпадает сразу.
И я бы хотел отметил предпоследнй вариант + из фреймворкав стоит отметить 960gs и Bootstrap
И я бы хотел отметил предпоследнй вариант + из фреймворкав стоит отметить 960gs и Bootstrap
Я помню несколько лет назад было подобное обсуждение по поводу использования фреймворков JavaScript. «Пуристы» были, предсказуемо, против, прагматики — всеми конечностями за. Теперь, вроде бы, почти все пользуются фреймворками. Причина популярности фреймворков для Javascript в частности в том, что базовые конструкции языка, сами по себе уже не отвечают потребностям современных интерфейсов и в том, что фреймворки маскируют различия в имплементации языка в разных браузерах. Если подойти к CSS фреймворкам с этой стороны, они предоставляют те-же преимущества. Например, общепринятая имплементация не поддерживает «из коробки» сетку.
Основной аргумент «против» заключается в том, что фреймворки до определенной степени навязывают структуру страницы и нарушают семантику документа.
Мне кажется что использовать фреймворки — это прагматичный шаг но, я надеюсь, что стандарт CSS со временем вберет в себя наиболее полезный функционал фреймворков.
Основной аргумент «против» заключается в том, что фреймворки до определенной степени навязывают структуру страницы и нарушают семантику документа.
Мне кажется что использовать фреймворки — это прагматичный шаг но, я надеюсь, что стандарт CSS со временем вберет в себя наиболее полезный функционал фреймворков.
Фреймворки — не каркасы же. Разные немного вещи, не? Путаю что-то?
Обычно каркасы — часть фреймворков, но наоборот не всегда верно — не в каждом фреймворке есть каркас.
Обычно каркасы — часть фреймворков, но наоборот не всегда верно — не в каждом фреймворке есть каркас.
Лет пять назад все JS фреймворки фреймворками стыдно называть было.
Есть сетки, которые не нарушают семантику, хотя они сложнее в освоении. Например goldengridsystem.com/
Использую Blueprint и Bootstrap. Практикую двухуровневый подход. Сначала проектируется сетка при помощи css-фреймворка, всем регионам определяются «говорящие» имена. Полученный таким образом макет можно оттемезировать на свой вкус, не боясь потери структуры.
Сам использую Bootstrap. На его основе, буквально за неделю реально все сверстать, и при этом все выглядит прилично, и с кросс-браузерностью проблем не много. Очень-очень удобно.
Боюсь только, что из-за этого удобства, интернет будет очень скоро заполонен одинаковыми Bootstrap-style сайтами. Приходится делать небольшие изменения (цвет navbar'a, иконки, и пр.).
Боюсь только, что из-за этого удобства, интернет будет очень скоро заполонен одинаковыми Bootstrap-style сайтами. Приходится делать небольшие изменения (цвет navbar'a, иконки, и пр.).
О, да. Именно этим он мне поначалу не понравился. Но похоже, это как первая доза, потом начинаешь вовсю юзать и слезть трудно. Особенно в связке с HTML5 Boilerplate. И ведь что характерно, такой сайт видно за версту, как ни раскрашивай.
Кстати, вот что это еще за мода на бекграунды с шумом? Понимаю, что пытаются имитировать грубый картон или бумагу, но выглядит имхо как-то грязно и далеко не везде к месту.
Кстати, вот что это еще за мода на бекграунды с шумом? Понимаю, что пытаются имитировать грубый картон или бумагу, но выглядит имхо как-то грязно и далеко не везде к месту.
Вы про фон navbar'a, что у меня на сайте driversworld.us? Я, честно, не думал, что это имитация картона/камня/кирпича/бетона. Мне просто показалось, что с шумом полоска выглядит повеселее.
>Боюсь только, что из-за этого удобства, интернет будет очень скоро заполонен одинаковыми Bootstrap-style сайтами
Мне думается, что, за некоторыми исключениями, «одинаковые сайты» — это неплохо. Если это сайт компании, то привычность вида элементов, предсказуемость навигации и т.д. — это плюс. Сайт — это всего лишь инструмент. И если это не инструмент самовыражения (сайт дизайн-студии, например), то чем он будет более «стандартным», тем лучше.
Мне думается, что, за некоторыми исключениями, «одинаковые сайты» — это неплохо. Если это сайт компании, то привычность вида элементов, предсказуемость навигации и т.д. — это плюс. Сайт — это всего лишь инструмент. И если это не инструмент самовыражения (сайт дизайн-студии, например), то чем он будет более «стандартным», тем лучше.
Что-то медленно вы верстаете, особенно учитывая использование готовой основы.
WEB 2.0 бессмысленный, беспощадный и одинаковый :)
Проголосовал за первый вариант.
Имхо, посмотрите на сайты на битриксе, сразу видно, что он на битриксе(если не перепилили половину битрикса).
Посмотрите на сайты на вордпрессе, джумле, друпале. Та же история.
Посмотрим на сайты на бутстрапе…
А если все-равно надо перепиливать, то зачем себе создавать лишние проблемы?
Проголосовал за первый вариант.
Имхо, посмотрите на сайты на битриксе, сразу видно, что он на битриксе(если не перепилили половину битрикса).
Посмотрите на сайты на вордпрессе, джумле, друпале. Та же история.
Посмотрим на сайты на бутстрапе…
А если все-равно надо перепиливать, то зачем себе создавать лишние проблемы?
jQuery UI — штука мерзопакостная, хоть и хорошая. Чтобы ее быстро кастомизировать надо из кожи вылезти. Причем самое забавное, что фотошоп при пересохранении ресурсов из jQuery UI ругается на гигантские имена файлов и автоматом их обрезает. Получается разработчики jQuery пользуются не фотошопом для создания графических ресурсов.
Собрал свой CSS каркас на 12 и 16 тянущихся колонок, который и использую при верстке (дизайнер тоже рисует макеты под сетку). Сейчас собираю нечто подобное Bootstrap для внутренних проектов, на основе существующих наработок.
jQuery UI не люблю из-за его монструозности, хотя для некоторых больших проектов использую. Остальные фреймворки из голосования в реальной жизни не использовал.
jQuery UI не люблю из-за его монструозности, хотя для некоторых больших проектов использую. Остальные фреймворки из голосования в реальной жизни не использовал.
Ввиду отсутствия в списке вариантов HTML Kickstart, воздержался от голосования.
Вообще, считаю использование css-framework'ов, равно как и препроцессоров, вроде haml, sass/compass, less etc. показателем профессионализма верстальщика, а никак не наоборот. Конечно, при условии что верстальщик понимает, что делает. Позицию свою основываю на индустриальности подхода, использующего фреймворки, по сравнению с ремесленностью pure-approach (неважно, pure-css, pure-html, pure-javascript или pure-assembler, подход «pure ради pure» — непрофессионален априори).
Вообще, считаю использование css-framework'ов, равно как и препроцессоров, вроде haml, sass/compass, less etc. показателем профессионализма верстальщика, а никак не наоборот. Конечно, при условии что верстальщик понимает, что делает. Позицию свою основываю на индустриальности подхода, использующего фреймворки, по сравнению с ремесленностью pure-approach (неважно, pure-css, pure-html, pure-javascript или pure-assembler, подход «pure ради pure» — непрофессионален априори).
Да пожалуй. Это — как на заре рунета хвастались, что сайт сделан в блокноте.
Профессиональный фотограф — это тётечка в пасспортном отделе, которая вас на мыльницу фоткает. Профессионализм — он разный.
ru.wikipedia.org/wiki/Профессионализм:
Люди часто путают профессию с профессионализмом, как вы. Но это заблуждение.
Профессионализм — особое свойство людей систематически, эффективно и надёжно выполнять сложную (профессиональную) деятельность в самых разнообразных условиях.
Люди часто путают профессию с профессионализмом, как вы. Но это заблуждение.
Шевчук однажды сказал «Сейчас наступило время профессионалов и все стремятся узнать как что то сделано..., а главный вопрос на который каждый должен для себя ответить это ЗАЧЕМ» (сокращено)
Я за все время работы верстальщиком не встретил ни одного раза когда бы мне понадобилось использовать какой то css-фреймверк. Если проект маленький то использовать фреймверки бессмысленно, а если большой то его нужно делать под каждый проект свой, специально оптимизированный для задач и стиля разрабатываемого проекта.
Так что я с вами категорически не соглашусь по вопросу о фреймверках и профессионализме:)
sass/compass, less одобряю, но тоже для решения определенных задач, скины и тд.
Я за все время работы верстальщиком не встретил ни одного раза когда бы мне понадобилось использовать какой то css-фреймверк. Если проект маленький то использовать фреймверки бессмысленно, а если большой то его нужно делать под каждый проект свой, специально оптимизированный для задач и стиля разрабатываемого проекта.
Так что я с вами категорически не соглашусь по вопросу о фреймверках и профессионализме:)
sass/compass, less одобряю, но тоже для решения определенных задач, скины и тд.
В данном случае ответ на вопрос "зачем" таков: "чтобы выполнить работу быстрее и надёжнее". Фреймворки (не важно, php-, python-, java-, javascript, или html/css-framework) — это прежде всего повторное использование кода. И оно не то чтобы нужно или может понадобиться — вполне можно обойтись и без него, как можно бриться опасной бритвой с мылом вместо станка с пеной. Оно просто позволяет выполнить ту же работу быстрее и надёжнее.
Выше в дереве комментариев возражали, что, мол, прироста скорости разработки на самом деле нет, по крайней мере отдельные разработчики таковой не обнаружили. На это у меня два контр-аргумента:
Выше в дереве комментариев возражали, что, мол, прироста скорости разработки на самом деле нет, по крайней мере отдельные разработчики таковой не обнаружили. На это у меня два контр-аргумента:
- мой личный опыт — однозначно говорит о том, что использование фреймворков ощутимо ускоряет прототипирование и вёрстку, а кроме того помогает в целом лучше организовать клиентскую сторону проекта. Более того, их использование упрощает дальнейшее развитие и поддержку проекта, что гораздо важнее.
- неизбежность повторного использования кода в том или ином виде — вряд ли кто-то станет спорить, что любой хоть сколько-нибудь опытный программист применяет в работе свои (и/или чужие) предшествующие наработки. Любой фреймворк — просто более оптимизированная для повторного использования «коллективная предшествующая наработка». Порог вхождения для его применения, безусловно, выше, чем порог вхождения для применения собственных наработок. Зато его поддерживает не один человек, использует не один человек, тестирует не один человек — и так далее, а в результате — надёжность велосипеда выше, и уехать на нём можно дальше.
Унификация всегда несет в себе ограничения ввиду отсутствия четкой фокусировки для выполнения определенных задач.
На определенном этапе в скорость написания кода больше начинает зависеть не от фреймверков, а от правильности и удобности темплейтов в багаже у специалиста. И в этом случае быстрее писать код с чистого листа чем использовать и модифицировать «велосипед который далеко ездит» :)
На определенном этапе в скорость написания кода больше начинает зависеть не от фреймверков, а от правильности и удобности темплейтов в багаже у специалиста. И в этом случае быстрее писать код с чистого листа чем использовать и модифицировать «велосипед который далеко ездит» :)
а кто вам мешает совмещать механизмы фреймворка и шаблонные решения из личного багажа знаний?
В таком общем виде — некорректно как в целом так и в частности. Обоснуйте и детализируйте, пожалуйста, свою мысль.
Унификация всегда несет в себе ограничения ввиду отсутствия четкой фокусировки для выполнения определенных задач.
В таком общем виде — некорректно как в целом так и в частности. Обоснуйте и детализируйте, пожалуйста, свою мысль.
Самый простой пример это разметка страницы в сетках. Для которой повсеместно используются классы типа «grid_1 prefix_8 suffix_3». Я не считаю что ради «ускорения» разработки нужно превращать свой код в такое.
Просто я привык верстать независимыми блоками с осмысленными именами классов, правильно построенной иерархией и структурой элементов и мне чужды идеи «ускорения» работы в ущерб качеству.
По моему мнению семантическая и структурная составляющая которая соответствует контенту по духу и букве :) это очень важно. Но я никому не навязываю свою точку зрения. :)
Просто я привык верстать независимыми блоками с осмысленными именами классов, правильно построенной иерархией и структурой элементов и мне чужды идеи «ускорения» работы в ущерб качеству.
По моему мнению семантическая и структурная составляющая которая соответствует контенту по духу и букве :) это очень важно. Но я никому не навязываю свою точку зрения. :)
Голосую за Bootstrap, все в одном флаконе.
Что за «CSS-каркас», это вы новое понятие придумали? Есть модульные сетки, есть CSS-фреймворки. А вот что такое «каркас» я понял только после намёков на Blueprint и 960gs.
Спасибо за критику, очень уважаю ваше мнение. Но, отчасти — цель данного опроса разобраться во всём этом безобразии, т.к. до профи мне очень далеко.
Создав вопрос в Q&A — на сегоднешний день, на него ответило менее десяти человек и самым грамотным был совет — спросить у более широкой аудитории в виде опроса.
А фреймворк — не русское какое-то слово, возможно, что не получилось предать смысл, используя другое.
Создав вопрос в Q&A — на сегоднешний день, на него ответило менее десяти человек и самым грамотным был совет — спросить у более широкой аудитории в виде опроса.
А фреймворк — не русское какое-то слово, возможно, что не получилось предать смысл, используя другое.
Ипользую только при создании закрытой от обычного пользователя части (админки, проще говоря). Для фронтенд-части, обычно много лишнего тянут за собой css-фреймворки.
Я лично предпочитаю максимально разделять зоны ответственности между различными частями вёрстки. Т.е. HTML отвечает за правильную структуру документа и семантику, CSS+JS — за отображение этой структуры в том виде как её задумал дизайнер. Именно эти принципы мешают мне использовать различные модульные сетки, т.к. в этом случае приходится в пределах одного HTML смешивать семантику и отображение (из-за использования классов типа «grid_1 prefix_8 suffix_3»).
Возможным решением в таком случае было бы наследование правил в CSS, что бы например я мог для своего класса «article» (или соответствующего тега из HTML5) указать наследование стилей из других правил (например классов «grid_1 prefix_8 suffix_3»).
Возможным решением в таком случае было бы наследование правил в CSS, что бы например я мог для своего класса «article» (или соответствующего тега из HTML5) указать наследование стилей из других правил (например классов «grid_1 prefix_8 suffix_3»).
less/sass/… этого не позволят? Я знаком с ними только по статьям на хабре, но может они могут вводить переменные/макросы не только в теле правила, но и в селекторах?
А есть какой-то смысл делать правильную (с какой точки зрения?) структуру документа и семантику?
Ну если не брать в расчёт вероятно более лучшую пресловутую индексируемость поисковиками, то как минимум смысл имеется в разделении функционала. И если HTML будет иметь сильную смысловую завязку на отображение, то при внесении изменений придётся либо править и CSS и HTML. Либо ломать шаблон и например неожиданно переместить в право столбец с классом left-column.
Само собой на данный момент совсем полное разделение функционала между HTML и CSS это из области теории, хотя бы потому, что в CSS пока нет достаточно хороших механизмов для гибкого управления расположением элементов на странице. Но как и любой идеал этот тоже имеет право, что бы к нему стремились.
Само собой на данный момент совсем полное разделение функционала между HTML и CSS это из области теории, хотя бы потому, что в CSS пока нет достаточно хороших механизмов для гибкого управления расположением элементов на странице. Но как и любой идеал этот тоже имеет право, что бы к нему стремились.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Допустимо ли использование CSS каркасов при разработке для веба?