Читая на другом форуме, я познакомился с миром CSS Framework. Я специально искал BluePrint . Мне было интересно, сталкивался ли кто-нибудь еще с фреймворками CSS, посоветуйте, какие из них лучше, и стоят ли они усилий?
Читая на другом форуме, я познакомился с миром CSS Framework. Я специально искал BluePrint . Мне было интересно, сталкивался ли кто-нибудь еще с фреймворками CSS, посоветуйте, какие из них лучше, и стоят ли они усилий?
Ответы:
«Фреймворки» CSS полностью упускают суть.
CSS не похож на JavaScript, где вы можете включить базовую библиотеку / фреймворк, а затем вызывать из нее функции и объекты для выполнения работы более высокого уровня. Все, что может дать CSS-фреймворк, - это декларативные правила: некоторые вещи по умолчанию для сброса правил браузера, некоторые стили классов, которые должны быть созданы для вашей страницы, и правила макета с использованием 'float' и 'clear'. Вы можете сами написать это в нескольких строках CSS, вместо того, чтобы тянуть за собой сотню рамочных правил.
В частности, «макет сетки» уходит корнями в старые плохие времена, когда вы смешивали презентацию с разметкой. 'div class = "span-24"' не лучше таблицы, вам придется вернуться туда и изменить разметку, чтобы повлиять на макет. И все фреймворки, которые я видел, основаны на плавающих блоках с фиксированными пикселями, что делает невозможным создание жидкого макета, доступного в широком диапазоне размеров окон.
Это обратная разработка, предназначенная только для тех, кто слишком напуган, чтобы писать правила CSS.
Итак, на этот вопрос еще никто не ответил (хотя я видел несколько положительных отзывов), поэтому Я собираюсь хотя бы попытаться ответить на второй вопрос в этой подсказке.
CSS-фреймворки великолепны; как и любой другой фреймворк, они сокращают время разработки и позволяют сразу же приступить к работе над дизайном для конкретного сайта и CSS. Они думают о трудных решениях, поэтому вам не нужно.
К сожалению, у использования фреймворка есть два недостатка (в целом):
Фреймворк определяет общую структуру и механизм вашего кода CSS. Я не говорю о сбросе CSS (они полезны сами по себе, но не являются настоящими фреймворками); Я говорю о честном и хорошем фреймворке, который уже принял решение о том, какие семантические теги вы собираетесь использовать в своем документе и т. Д. Таким образом, вы становитесь зависимыми от фреймворка, и когда возникает ошибка в рамках, вам, как правило, придется исправить это самостоятельно.
Фреймворки не могут служить оправданием для игнорирования кроссбраузерности / продвинутых проблем CSS. Вы неизбежно столкнетесь с ними, как если бы вы работали с фреймворком PHP или JavaScript. И нужно знать, как с ними бороться. Часто говорят, что сначала нужно написать свой собственный фреймворк, прежде чем использовать чужой.
Взглянув на Blueprint, я бы не стал называть это фреймворком; возможно, сброс с парочкой дополнительных плюшек наверху.
Я посмотрел на BluePrint и несколько других, и единственная CSS-структура, которую я рекомендую, - это YUI Grids.
Плюсы:
Минусы:
Как уже писали другие, реальных «фреймворков» для CSS нет. Сброс таблиц стилей также очень помогает с макетом. Я обычно придерживаюсь таблицы стилей сброса и продолжаю оттуда. Но если у вас нет большого опыта работы с CSS, YUI Grids может сэкономить вам время.
Найдите время, чтобы изучить и понять (действительно понять!) Несколько фреймворков CSS, таких как BluePrint и YUI, и сбросить CSS, как Эрик Мейер. Затем найдите время, чтобы собрать свой собственный сброс и / или фреймворк в зависимости от ваших методов работы и типа создаваемых вами сайтов.
Лично я использую большую часть сброса Эрика Мейера с некоторыми собственными классами и сбросами, а также несколько идей из BluePrint и YUI.
Я недавно наблюдал, как Эрик Мейер выступал с презентацией CSS Frameworks, в которой он задал вопрос: «Так какой из них мне подходит?» Затем он ответил на вопрос, показав пустой слайд. Его точка зрения заключалась в том, что, безусловно, есть некоторые полезные концепции, встроенные в большинство сбросов и фреймворков, но лучше всего вам подойдет тот, который вы пишете для себя (оно того стоит).
Зачем использовать css 'frameworks'?
Если вам не хватает времени.
Если вы не знаете css и не знаете кого-нибудь, кто может написать это за вас.
Если вы не слишком дорожите стандартами и т. Д.
Я знаю программистов, которые были действительно счастливы использовать blueprint или 960, поскольку он позволяет им создавать макет самостоятельно, не обращаясь к фронтенд-разработчику. Это идеально подходит для личных проектов или стартапов с ограниченными ресурсами.
Если у вас уже есть приличные знания CSS, то, вероятно, у вас уже есть приличная библиотека стандартных макетов, поэтому вам явно не понадобится фреймворк.
Однако, если вы новичок и вам просто нужно что-то запустить и запустить, вы можете обратиться к фреймворку, поскольку он значительно упрощает базовый макет, а также решает проблему совместимости с браузером.
Сказав все это, многие фреймворки из коробки действительно используют некоторые ужасные имена классов и т. Д. Я знаю некоторые веб-сайты, которые взяли фреймворк в качестве отправной точки, а затем настроили его с помощью своих собственных тегов class и id. Но очевидно, что и с этим переписыванием нужно немного поработать. Использование чего-то вроде Compass, как упоминалось выше, действительно помогает обойти это.
Итак, CSS-фреймворки - они могут сэкономить ваше время за счет семантики. Они также могут повредить вашим знаниям CSS, но это больше зависит от того, сколько вы вкладываете в изучение предмета в целом. Использовать ли вы их - решать вам.
Вы должны спросить себя, насколько эффективны доступные фреймворки для решения ваших проблем. Отвечают ли они вашим требованиям?
Используя фреймворк, вы можете установить некоторые правила или детали на уровне пикселей и посвятить остальное время их реализации и производству. Это огромный рост производительности. Если вы обнаружите, что тратите время на корректировку вещей на несколько пикселей в конце проекта (микроуправление дизайном), это признак того, что фреймворк может быть полезен.
Совет № 17 в «Программисте-прагматике» гласит: «Программируйте ближе к проблемной области». Использование слоя абстракции может приблизить вас к решению реальных проблем макета. Например: вы можете сконцентрироваться на улучшении взаимодействия с пользователем за счет дополнительного времени, а не незначительных корректировок пикселей.
Это не означает, что вы должны жертвовать качеством ради количества. Дело в эффективности.
В недавнем проекте я создал свой собственный фреймворк, потому что у нас были очень ограниченные ресурсы, а популярные фреймворки не делали того, что я хотел. Затем я настроил PSD команды дизайнеров для привязки к той же сетке, которую я развернул.
Фреймворк не обязательно должен быть какой-то конкретной реализацией CSS. Это не обязательно должно быть что-то раздутое, что вы скачали из интернета, или что-то, реализующее устаревшие идеи. Это просто техника для выполнения работы. Не удивлюсь, если у некоторых программистов уже есть собственные фреймворки, и они даже не знают об этом. Фактически, если вы рассматриваете DOM как набор элементов по умолчанию, расширяемых с помощью CSS, то это структура по определению.
На самом деле я потратил большую часть последних 24 часов, исследуя это самостоятельно, хех. Я пришел к выводу, что хороший сброс (я использовал YUI Reset ) и, возможно, что-то еще, чтобы установить базовые параметры ( в моем случае были полезны шрифты YUI ; возможно, «дополнительные вкусности» BluePrint будут в вашем) - хорошая идея. Но «фреймворк» - который обычно представляет собой что-то вроде сеток YUI - слишком ограничен, вынуждая вас использовать их имена классов, идентификаторы и т. Д. И редко вписывается в ваш сайт, как это сделал бы ручной CSS.
Короче говоря: сбросы кажутся довольно хорошими; хорошо устранить все вариации, например, в отношении полей и заполнений для списков, или интервалов между абзацами, или чего-то еще. Но это все, что я могу сказать.
Компас считаю потрясающим. Убедитесь, что вы видите скринкаст .
Я использую 960.gs для нескольких веб-сайтов и считаю его очень простым и легким, и оно того стоит. Экономит мне много работы по верстке. Обязательно проверьте настраиваемый генератор CSS, у которого фиксированная ширина составляет 960 пикселей.
Я думаю, что эта видеопрезентация генерального директора Site Point Кевина Янка ответит на ваш вопрос. Очень рекомендую его посмотреть.
Compass позволяет вам переименовывать классы и идентификаторы вашего фреймворка с вашими собственными семантическими именами, так что вы, возможно, захотите проверить это. Он также обеспечивает доступ к тому, чего вы просто не получите с помощью обычного CSS, например миксинам.
Я поражен так называемыми «экспертами по CSS», которые критикуют эти инструменты, даже не вникая в них и не используя их. Они необходимы? Нет. Если вам нравится ваш собственный фреймворк (у вас ведь есть собственный фреймворк, не так ли? CSS-фреймворк - это просто тщательно определенная библиотека - каждый должен его использовать), то непременно продолжайте его использовать. Никто не заставляет вас использовать другие фреймворки, и я не вижу людей, которые используют фреймворки, говорящие пуристам CSS, что они «делают это неправильно».
Критика фреймворков с такой точки зрения просто свидетельствует о незащищенности, а также о невежестве. Например, смехотворно мнение, что человек будет использовать такой инструмент, как Compass, не зная CSS. Вы ведь понимаете, что фреймворк обычно не пишет за вас весь CSS? Вы все еще можете разобраться и написать свой собственный CSS в контексте большинства фреймворков. Фактически, если вы не знаете CSS, вы можете быстро разочароваться.
Для себя я ценю наличие фреймворка, потому что он уже задокументирован, протестирован сотнями других пользователей, и я могу применять свои собственные классы и идентификаторы через Compass. Если мне нужно что-то, для чего фреймворк не подходит, я буду писать код самостоятельно.
Мэтт Рейбл из AppFuse некоторое время назад провел конкурс CSS Framework для разработки CSS Frameworks для AppFuse. Результаты опубликованы здесь . Есть несколько вариантов, и я использовал их сам, потому что использую AppFuse и считаю их очень хорошими.
Я должен добавить, что эти CSS Framework хорошо работают, потому что они используются в тематических приложениях. То есть, если вы придерживаетесь правил, то переключение с одного на другое так же просто, как изменение одного значения в файле свойств.
Я с большим успехом использовал BluePrint на сайте (я мог бы упомянуть этот сайт здесь, но я уверен, что сообщение будет отмечено как спам!). Я не уверен, буду ли я использовать его в будущем, потому что одна из идей CSS, которую я думал, заключалась в том, чтобы не иметь жестко запрограммированной логики макета. У вас не должно быть элементов css с именами span-24 и span-12 для определения макета, а что-то вроде searchBox и mainContent. По крайней мере, так я это вижу.
Хорошая ссылка, которую я нашел: 12 лучших CSS-фреймворков и способы их понимания
Вот моя запись в блоге о CSS Framework. Когда использовать CSS framework?
Единственный известный мне способ использовать структуру CSS и сохранить семантическую разметку - это использовать абстракцию более высокого уровня. На данный момент Compass - единственный, о котором я знаю, достаточно зрелый для использования, но Николь Салливан, похоже, делает кое-что интересное в своем проекте «Объектно-ориентированный CSS».
Я считаю, что умное использование примесей Sass в Compass является блестящим достижением и большим шагом к Святому Граалю поддерживаемой семантической разметки. Я не думаю, что я хотел бы использовать фреймворк, такой как Blueprint или YUI, без абстракции, такой как Compass, чтобы классы представления не попадали в разметку.
Кстати, есть красивый CSS-фреймворк под названием Elastic, который выглядит достаточно хорошо, и я подумываю добавить его в Compass.
Я считаю, что CSS - это простота. Цель состоит в том, чтобы иметь одно или два места для проверки, когда вы ссылаетесь между HTML и таблицей стилей. Добавление большего количества строк, и особенно строк, которые вы не писали и, вероятно, не так хорошо знакомы, экспоненциально увеличит сложность и, следовательно, изменчивость кода CSS.
Я бы предложил ваши макеты по мере их написания и разработать на их основе общую систему шаблонов. Хотя мне нравится делать CSS более модульным, часто и в зависимости от дизайна ваш CSS может быть очень специфичным для конкретного случая и совсем не модульным.
Я использовал Blueprint на нескольких разовых сайтах, и это определенно сэкономило время, в первую очередь при кроссбраузерном тестировании.
Это определенно отстой, добавляя код презентации в разметку, хотя, с другой стороны, он удобочитаем. Хотя мне нравится концепция «вы можете изменить дизайн, не касаясь разметки», если вы создаете сайт, на котором этого действительно не произойдет, и вам просто нужно, чтобы это было сделано вчера, Blueprint - это то, на что стоит обратить внимание.
Однако существуют также компромиссы в том, какие типы макетов можно создать. Если вы с самого начала создадите каркас сайта по строгой сетке, будет намного проще перенести его в рамки с минимумом хлопот.
Я использовал BluePrint и YUI, но меня всегда разочаровывают некоторые имена, которые они дают своим идентификаторам и классам.
Каждому свое, но я предпочитаю делать что-то с нуля, но через некоторое время вы разрабатываете процесс, в котором вы будете использовать свою предыдущую работу и применять ее к новым проектам и просто вносите некоторые изменения, чтобы сайт выглядел так, как вы нравится.
Обязательно используйте хорошее соглашение об именах, на всякий случай, если кто-то еще придет отредактировать CSS, тогда они будут иметь хорошее представление о том, к чему относится каждое имя стиля.
Крейг,
Compass - это то, что вы ищете: он позволяет вам переименовывать классы CSS Blueprint, например, span-24, с вашими собственными именами. Он также расширяет функциональность CSS с помощью переменных и миксинов. Действительно, те, кто преждевременно судит о фреймворках, не проверив Compass, «упускают из виду». Это похоже на людей, которые много лет назад сказали нам, что мы упускаем из виду суть, используя CSS вместо HTML-таблиц для наших макетов.
-Матт
посетите http://www.ez-css.org/ . один из самых простых и легких фреймворков css для работы. :)
Взгляните на эту демонстрацию: http://www.richstyle.org/demo-web.php Эта структура основана на идее, что «HTML-тегов должно быть достаточно». Я считаю, что возможность повторного использования является наиболее важным фактором при выборе программного компонента, включая веб-фреймворк. Для разработчиков веб-фреймворков, чем больше вы придерживаетесь стандартов, тем больше вы гарантируете возможность повторного использования.