Допустимо ли использование CSS каркасов при разработке для веба?

     

    Only registered users can participate in poll. Log in, please.

    Допустимо ли использование CSS каркасов при разработке для веба?

    • 15.3%Допустимо только в случае, когда дизайнером подготовлен макет с использованьем стандартной сетки фреймворка.369
    • 8.7%Допустимо. Предпочитаю использовать 960gs.210
    • 0.3%Допустимо. Предпочитаю использовать Baseline.9
    • 2.4%Допустимо. Предпочитаю использовать Blueprint.60
    • 22.2%Допустимо. Предпочитаю использовать Bootstrap.534
    • 11.6%Допустимо. Предпочитаю использовать jQuery UI.279
    • 0.5%Допустимо. Предпочитаю использовать YUI CSS Grids.13
    • 26.2%Считаю использованье CSS каркасов допустимым, но не предпочтительным вариантом.631
    • 12.4%Считаю использованье CSS каркасов — проявлением низкой квалификации верстальщика.298
    Share post

    Similar posts

    Comments 54

      +1
      Казалось бы, причем здесь jQuery UI.
        +3
        Когда я задавал вопрос в Q&A, я тоже удивился. Но перед тем, как спрашивать ознакомился с вопросом.
        Cсылка.
        +3
        Считаю что для создание прототипа css фреймворки — самое то. Сам проголосовал за Bootstrap.
          +2
          Вопрос, как я понял, не про прототипы и фреймворки, а про верстку вообще и готовые сетки.
            0
            К сожалению, bootstrap так и не пользовал, но тоже проголосовал за него. Если буду делать frontend интерфейс — выбор уже сделан. Для backend использую ExtJS.
              +1
              Подскажите, как можно использовать ExtJS для backend? Под backend обычно подразумевается серверная сторона, а под frontend — браузерная, я прав? Или Вы подразумеваете что-то другое?
                0
                Здесь backend имелось в виду личный кабинет пользователя, а frontend — сайт компании. На frontend, как на корпоративном сайте, нельзя использовать ExtJs из-за его объема и сложности адаптации для мобильных устройств. При этом, для личного кабинета ExtJS вполне подходит.
            +1
            Проголосовал за Bootstrap. Огромным плюсом считаю то, что в нем возможна гибкая настройка параметров сетки. Так что достаточно просто попросить дизайнера делать макеты с сеткой, а дальше уже дело техники
              +3
              Да как на войне, все допустимо, вопрос только в целесообразности. Я б рад использовать какие-то фреймворки для ускорения верстки, но никакого ускорения, даже в перспективе, не заметил.
                0
                Значит у вас такие проекты, если вы не заметили ускорения. Но даже на средних проектах, первоначально оно может незаметно, но если проект будет расти и изменяться вас будут меньше дергать программисты что-бы свёрстать ещё один «нестандартный» блочек, уж поверьте.
                  0
                  «Нестандартный» блочек — увольте программистов.
                    0
                    На мой взгляд нужно не программистов увольнять, а людей которые эту ситуацию допустили.
                0
                Я считаю, что используя фреймворк разработчик безусловно должен понимать что он делает, а не просто лепить классы по примеру! Также использовать фрейм ворк только в том случае если дизайнер рисовал для дизайн четко по требованиям фреймворка! Если дизайн райндомный то все отпадает сразу.
                И я бы хотел отметил предпоследнй вариант + из фреймворкав стоит отметить 960gs и Bootstrap
                  0
                  Та же самая ситуация, что и с веб-приложениями. Фреймворк подходит под 99% потребносетй, а там, где не подходит — программисты(которые все равно знают несколько популярных фреймворков) отчетливо понимают, на что идут для определенной задачи.
                    +5
                    Я помню несколько лет назад было подобное обсуждение по поводу использования фреймворков JavaScript. «Пуристы» были, предсказуемо, против, прагматики — всеми конечностями за. Теперь, вроде бы, почти все пользуются фреймворками. Причина популярности фреймворков для Javascript в частности в том, что базовые конструкции языка, сами по себе уже не отвечают потребностям современных интерфейсов и в том, что фреймворки маскируют различия в имплементации языка в разных браузерах. Если подойти к CSS фреймворкам с этой стороны, они предоставляют те-же преимущества. Например, общепринятая имплементация не поддерживает «из коробки» сетку.

                    Основной аргумент «против» заключается в том, что фреймворки до определенной степени навязывают структуру страницы и нарушают семантику документа.

                    Мне кажется что использовать фреймворки — это прагматичный шаг но, я надеюсь, что стандарт CSS со временем вберет в себя наиболее полезный функционал фреймворков.
                      +1
                      Фреймворки — не каркасы же. Разные немного вещи, не? Путаю что-то?

                      Обычно каркасы — часть фреймворков, но наоборот не всегда верно — не в каждом фреймворке есть каркас.
                        +1
                        Один из основных переводов «framework» на русский как раз «каркас», то есть используемый фреймворк определяет структуру создаваемого кода. Если не определяет, а создаваемый код просто его использует, то, имхо, этот «фреймворк» скорее библиотека.

                          0
                          Спасибо, а то я думал, что живу в параллельной вселенной и перевод там не такой как в этой.
                        0
                        Лет пять назад все JS фреймворки фреймворками стыдно называть было.
                          0
                          Есть сетки, которые не нарушают семантику, хотя они сложнее в освоении. Например goldengridsystem.com/
                          0
                          Использую Blueprint и Bootstrap. Практикую двухуровневый подход. Сначала проектируется сетка при помощи css-фреймворка, всем регионам определяются «говорящие» имена. Полученный таким образом макет можно оттемезировать на свой вкус, не боясь потери структуры.
                            0
                            Сам использую Bootstrap. На его основе, буквально за неделю реально все сверстать, и при этом все выглядит прилично, и с кросс-браузерностью проблем не много. Очень-очень удобно.

                            Боюсь только, что из-за этого удобства, интернет будет очень скоро заполонен одинаковыми Bootstrap-style сайтами. Приходится делать небольшие изменения (цвет navbar'a, иконки, и пр.).
                              0
                              О, да. Именно этим он мне поначалу не понравился. Но похоже, это как первая доза, потом начинаешь вовсю юзать и слезть трудно. Особенно в связке с HTML5 Boilerplate. И ведь что характерно, такой сайт видно за версту, как ни раскрашивай.
                              Кстати, вот что это еще за мода на бекграунды с шумом? Понимаю, что пытаются имитировать грубый картон или бумагу, но выглядит имхо как-то грязно и далеко не везде к месту.
                                0
                                Вы про фон navbar'a, что у меня на сайте driversworld.us? Я, честно, не думал, что это имитация картона/камня/кирпича/бетона. Мне просто показалось, что с шумом полоска выглядит повеселее.
                                  0
                                  Я, если честно, до этого комментария Ваш сайт не видел. Пальцем в небо, как говорится =)
                                +2
                                >Боюсь только, что из-за этого удобства, интернет будет очень скоро заполонен одинаковыми Bootstrap-style сайтами

                                Мне думается, что, за некоторыми исключениями, «одинаковые сайты» — это неплохо. Если это сайт компании, то привычность вида элементов, предсказуемость навигации и т.д. — это плюс. Сайт — это всего лишь инструмент. И если это не инструмент самовыражения (сайт дизайн-студии, например), то чем он будет более «стандартным», тем лучше.
                                  0
                                  Что-то медленно вы верстаете, особенно учитывая использование готовой основы.
                                  0
                                  WEB 2.0 бессмысленный, беспощадный и одинаковый :)
                                  Проголосовал за первый вариант.
                                  Имхо, посмотрите на сайты на битриксе, сразу видно, что он на битриксе(если не перепилили половину битрикса).
                                  Посмотрите на сайты на вордпрессе, джумле, друпале. Та же история.
                                  Посмотрим на сайты на бутстрапе…

                                  А если все-равно надо перепиливать, то зачем себе создавать лишние проблемы?

                                    +1
                                    Не на все сайты ходят для того, что бы смотреть на вёрстку.
                                      0
                                      Вот даже не знаю, что ответить.
                                      Я говорю, что бутстрап не панацея, и что решение по использованию CSS каркасов зависит от дизайна.
                                      0
                                      кто же мешает натянуть бутстрап на любую цмс?
                                      0
                                      jQuery UI — штука мерзопакостная, хоть и хорошая. Чтобы ее быстро кастомизировать надо из кожи вылезти. Причем самое забавное, что фотошоп при пересохранении ресурсов из jQuery UI ругается на гигантские имена файлов и автоматом их обрезает. Получается разработчики jQuery пользуются не фотошопом для создания графических ресурсов.
                                        +1
                                        Водка не только вредная, но и полезная.
                                        0
                                        Собрал свой CSS каркас на 12 и 16 тянущихся колонок, который и использую при верстке (дизайнер тоже рисует макеты под сетку). Сейчас собираю нечто подобное Bootstrap для внутренних проектов, на основе существующих наработок.

                                        jQuery UI не люблю из-за его монструозности, хотя для некоторых больших проектов использую. Остальные фреймворки из голосования в реальной жизни не использовал.
                                          +2
                                          Ввиду отсутствия в списке вариантов HTML Kickstart, воздержался от голосования.
                                          Вообще, считаю использование css-framework'ов, равно как и препроцессоров, вроде haml, sass/compass, less etc. показателем профессионализма верстальщика, а никак не наоборот. Конечно, при условии что верстальщик понимает, что делает. Позицию свою основываю на индустриальности подхода, использующего фреймворки, по сравнению с ремесленностью pure-approach (неважно, pure-css, pure-html, pure-javascript или pure-assembler, подход «pure ради pure» — непрофессионален априори).
                                            0
                                            Да пожалуй. Это — как на заре рунета хвастались, что сайт сделан в блокноте.
                                              0
                                              Профессиональный фотограф — это тётечка в пасспортном отделе, которая вас на мыльницу фоткает. Профессионализм — он разный.
                                                0
                                                ru.wikipedia.org/wiki/Профессионализм:
                                                Профессионализм — особое свойство людей систематически, эффективно и надёжно выполнять сложную (профессиональную) деятельность в самых разнообразных условиях.

                                                Люди часто путают профессию с профессионализмом, как вы. Но это заблуждение.
                                                  0
                                                  Люди часто путают профессионализ и мастерство. Особенно в русской вики, например. A professional is a person who is paid to undertake a specialised set of tasks and to complete them for a fee.
                                                0
                                                Шевчук однажды сказал «Сейчас наступило время профессионалов и все стремятся узнать как что то сделано..., а главный вопрос на который каждый должен для себя ответить это ЗАЧЕМ» (сокращено)

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

                                                Так что я с вами категорически не соглашусь по вопросу о фреймверках и профессионализме:)

                                                sass/compass, less одобряю, но тоже для решения определенных задач, скины и тд.
                                                  +1
                                                  В данном случае ответ на вопрос "зачем" таков: "чтобы выполнить работу быстрее и надёжнее". Фреймворки (не важно, php-, python-, java-, javascript, или html/css-framework) — это прежде всего повторное использование кода. И оно не то чтобы нужно или может понадобиться — вполне можно обойтись и без него, как можно бриться опасной бритвой с мылом вместо станка с пеной. Оно просто позволяет выполнить ту же работу быстрее и надёжнее.
                                                  Выше в дереве комментариев возражали, что, мол, прироста скорости разработки на самом деле нет, по крайней мере отдельные разработчики таковой не обнаружили. На это у меня два контр-аргумента:
                                                  • мой личный опыт — однозначно говорит о том, что использование фреймворков ощутимо ускоряет прототипирование и вёрстку, а кроме того помогает в целом лучше организовать клиентскую сторону проекта. Более того, их использование упрощает дальнейшее развитие и поддержку проекта, что гораздо важнее.
                                                  • неизбежность повторного использования кода в том или ином виде — вряд ли кто-то станет спорить, что любой хоть сколько-нибудь опытный программист применяет в работе свои (и/или чужие) предшествующие наработки. Любой фреймворк — просто более оптимизированная для повторного использования «коллективная предшествующая наработка». Порог вхождения для его применения, безусловно, выше, чем порог вхождения для применения собственных наработок. Зато его поддерживает не один человек, использует не один человек, тестирует не один человек — и так далее, а в результате — надёжность велосипеда выше, и уехать на нём можно дальше.
                                                    +2
                                                    Унификация всегда несет в себе ограничения ввиду отсутствия четкой фокусировки для выполнения определенных задач.

                                                    На определенном этапе в скорость написания кода больше начинает зависеть не от фреймверков, а от правильности и удобности темплейтов в багаже у специалиста. И в этом случае быстрее писать код с чистого листа чем использовать и модифицировать «велосипед который далеко ездит» :)
                                                      0
                                                      а кто вам мешает совмещать механизмы фреймворка и шаблонные решения из личного багажа знаний?

                                                      Унификация всегда несет в себе ограничения ввиду отсутствия четкой фокусировки для выполнения определенных задач.

                                                      В таком общем виде — некорректно как в целом так и в частности. Обоснуйте и детализируйте, пожалуйста, свою мысль.
                                                        +1
                                                        Самый простой пример это разметка страницы в сетках. Для которой повсеместно используются классы типа «grid_1 prefix_8 suffix_3». Я не считаю что ради «ускорения» разработки нужно превращать свой код в такое.

                                                        Просто я привык верстать независимыми блоками с осмысленными именами классов, правильно построенной иерархией и структурой элементов и мне чужды идеи «ускорения» работы в ущерб качеству.

                                                        По моему мнению семантическая и структурная составляющая которая соответствует контенту по духу и букве :) это очень важно. Но я никому не навязываю свою точку зрения. :)
                                                          0
                                                          согласен, во всём важна умеренность и здравый смысл.
                                                0
                                                Голосую за Bootstrap, все в одном флаконе.
                                                  +1
                                                  Что за «CSS-каркас», это вы новое понятие придумали? Есть модульные сетки, есть CSS-фреймворки. А вот что такое «каркас» я понял только после намёков на Blueprint и 960gs.
                                                    0
                                                    Спасибо за критику, очень уважаю ваше мнение. Но, отчасти — цель данного опроса разобраться во всём этом безобразии, т.к. до профи мне очень далеко.
                                                    Создав вопрос в Q&A — на сегоднешний день, на него ответило менее десяти человек и самым грамотным был совет — спросить у более широкой аудитории в виде опроса.

                                                    А фреймворк — не русское какое-то слово, возможно, что не получилось предать смысл, используя другое.
                                                      +2
                                                      Слово «бутерброд» тоже когда-то было нерусским. В любом случае, речь идёт о профессиональной лексике, а она активно впитывает англицизмы.
                                                    +1
                                                    Ипользую только при создании закрытой от обычного пользователя части (админки, проще говоря). Для фронтенд-части, обычно много лишнего тянут за собой css-фреймворки.
                                                      +1
                                                      Я лично предпочитаю максимально разделять зоны ответственности между различными частями вёрстки. Т.е. HTML отвечает за правильную структуру документа и семантику, CSS+JS — за отображение этой структуры в том виде как её задумал дизайнер. Именно эти принципы мешают мне использовать различные модульные сетки, т.к. в этом случае приходится в пределах одного HTML смешивать семантику и отображение (из-за использования классов типа «grid_1 prefix_8 suffix_3»).

                                                      Возможным решением в таком случае было бы наследование правил в CSS, что бы например я мог для своего класса «article» (или соответствующего тега из HTML5) указать наследование стилей из других правил (например классов «grid_1 prefix_8 suffix_3»).
                                                        0
                                                        less/sass/… этого не позволят? Я знаком с ними только по статьям на хабре, но может они могут вводить переменные/макросы не только в теле правила, но и в селекторах?
                                                          0
                                                          А есть какой-то смысл делать правильную (с какой точки зрения?) структуру документа и семантику?
                                                            0
                                                            Ну если не брать в расчёт вероятно более лучшую пресловутую индексируемость поисковиками, то как минимум смысл имеется в разделении функционала. И если HTML будет иметь сильную смысловую завязку на отображение, то при внесении изменений придётся либо править и CSS и HTML. Либо ломать шаблон и например неожиданно переместить в право столбец с классом left-column.

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

                                                        Only users with full accounts can post comments. Log in, please.