Какая CSS-фреймворк самая лучшая и стоят ли они затраченных усилий?

«Фреймворки» CSS полностью упускают из виду суть.

CSS не похож на JavaScript, где вы можете включить базовую библиотеку / фреймворк, а затем вызывать из нее функции и объекты для выполнения работы более высокого уровня. Все, что может дать CSS-фреймворк, - это декларативные правила: некоторые вещи по умолчанию для сброса правил браузера, некоторые стили классов, которые необходимо использовать для создания вашей страницы, и правила макета с использованием 'float' и 'clear'. Вы можете написать это в нескольких строках CSS самостоятельно, вместо того, чтобы тянуть за собой сотню рамочных правил.

В частности, материал «макета сетки» восходит к плохим старым временам, когда ваша презентация смешивалась с разметкой. 'div class = "span-24"' не лучше таблицы, вам придется вернуться туда и изменить разметку, чтобы повлиять на макет. И все фреймворки, которые я видел, основаны на плавающих блоках с фиксированными пикселями, что делает невозможным создание жидкого макета, доступного в широком диапазоне размеров окон.

Это обратное создание, предназначенное только для тех, кто слишком напуган, чтобы писать правила CSS.

Итак, на этот вопрос пока никто не ответил (хотя я видел несколько положительных отзывов), поэтому Я собираюсь хотя бы попытаться ответить на второй вопрос в этой подсказке.

CSS-фреймворки великолепны; как и любой другой фреймворк, они сокращают время разработки и позволяют сразу же приступить к работе над дизайном для конкретного сайта и CSS. Они думают о трудных решениях, поэтому вам не нужно.

К сожалению, у использования фреймворка есть два недостатка (в целом):

1. Фреймворк определяет общую структуру и механику вашего кода CSS. Я не говорю о сбросе CSS (они полезны сами по себе, но это не настоящие фреймворки); Я говорю о честном и хорошем фреймворке, который уже принял решение о том, какие семантические теги вы собираетесь использовать в своем документе и т. д. Таким образом, вы становитесь зависимыми от фреймворка, и когда возникает ошибка в фреймворке вам, как правило, придется исправить это самостоятельно.

2. Фреймворки не могут служить оправданием для игнорирования кроссбраузерности / продвинутых проблем CSS. Вы неизбежно столкнетесь с ними, как если бы вы работали с фреймворком PHP или JavaScript. И нужно знать, как с ними бороться. Часто говорят, что сначала нужно написать свой собственный фреймворк, прежде чем использовать чужой.

Взглянув на Blueprint, я бы не назвал это фреймворком; может быть, сброс с парочкой дополнительных плюшек наверху.

Я просмотрел BluePrint и несколько других, и я бы порекомендовал единственную CSS-фреймворк YUI Grids.

Плюсы:

• Написано одним из лучших фронтенд-инженеров (ИМО) (Нейт Кочли)
• Очень маленький. 4 КБ
• Очень гибкий (1000 различных макетов)
• Поддерживает макеты с изменяемой шириной (100%), а также предустановленные макеты с фиксированной шириной 750 пикселей, 950 пикселей и 974 пикселей, а также возможность легкой настройки на любое число.
• Поддерживает легкую настройку ширины для макетов с фиксированной шириной.
• Столбцы шаблонов не зависят от порядка источников, поэтому вы можете поместить наиболее важный контент на первое место в слое разметки для повышения доступности и оптимизации для поисковых систем (SEO).
• Самоочищающийся нижний колонтитул. Независимо от того, какой столбец длиннее, нижний колонтитул остается внизу.
• Макеты менее 100% автоматически центрируются.
• Несколько семантических имен классов (лучше, чем верхний, левый, правый и т. д.)

Минусы:

• Множество дополнительной разметки по сравнению с рукописным HTML и CSS
• Требуется некоторое обучение, чтобы понять, как создавать сложные макеты.

Как уже писали другие, настоящих «фреймворков» для CSS нет. Таблицы стилей Сброс настроек также очень помогают с разметкой. Я обычно придерживаюсь таблицы стилей сброса и перехожу к ней. Но если у вас нет большого опыта работы с CSS, YUI Grids может сэкономить вам время.

Мэтт Рэйбл из AppFuse некоторое время назад провел конкурс CSS Framework для разработки CSS Frameworks для AppFuse. Результаты опубликованы здесь. Есть несколько вариантов, и я использовал некоторые из них, потому что использую AppFuse и считаю их очень хорошими.

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

На самом деле я потратил большую часть последних 24 часов, исследуя это самостоятельно, хех. Я пришел к выводу, что хороший сброс (я использовал YUI Сброс) и, возможно, что-то еще, чтобы установить базовые параметры (Шрифты YUI был полезным в моем случае; возможно, "дополнительные вкусности" BluePrint были бы в вашем) - хорошая идея. Но «фреймворк», который обычно представляет собой что-то вроде Сетки YUI, является слишком ограничительным, вынуждая вас использовать их имена классов, идентификаторы и т. д. И редко вписывается в ваш сайт, как это сделал бы ручной CSS.

Короче говоря: сбросы кажутся довольно хорошими; хорошо исключить все вариации, например, margin-vs-padding для списков, или интервал между абзацами, или что-то еще. Но это все, что я могу сказать.

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

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

Я использовал Blueprint на нескольких разовых сайтах, и это определенно сэкономило время, в первую очередь при кроссбраузерном тестировании.

Это определенно отстой, добавляя код презентации в разметку, хотя, с другой стороны, он удобочитаем. Хотя мне нравится концепция «вы можете изменить дизайн, не касаясь разметки», если вы создаете сайт, на котором этого в любом случае не произойдет, и вам просто нужно, чтобы это было сделано вчера, Blueprint - это то, на что стоит обратить внимание.

Однако есть также компромиссы в том, какие типы макетов можно создать. Если вы с самого начала создадите каркас сайта по строгой сетке, будет намного проще перенести его в рамки с минимумом хлопот.

Я с большим успехом использовал BluePrint на сайте (я мог бы упомянуть этот сайт здесь, но я уверен, что сообщение будет отмечено как спам!). Я не уверен, буду ли я использовать его в будущем, потому что одна из идей CSS, которую я думал, заключалась в том, чтобы не иметь жестко запрограммированной логики макета. У вас не должно быть элементов css с именами span-24 и span-12 для определения макета, а что-то вроде searchBox и mainContent. По крайней мере, так я это вижу.

Найдите время, чтобы изучить и понять (действительно понять!) Несколько фреймворков CSS, таких как BluePrint и YUI, и сбросить CSS, как Эрик Мейер. Затем найдите время, чтобы собрать свой собственный сброс и / или фреймворк на основе ваших методов работы и типа создаваемых вами сайтов.

Лично я использую большую часть сброса Эрика Мейера с некоторыми собственными классами и сбросами, а также несколько идей из BluePrint и YUI.

Я недавно наблюдал, как Эрик Мейер выступал с презентацией CSS Frameworks, в которой он задал вопрос: «Так какой из них мне подходит?» Затем он ответил на вопрос, показав пустой слайд. Его точка зрения заключалась в том, что, безусловно, есть некоторые полезные концепции, встроенные в большинство сбросов и фреймворков, но лучше всего вам подойдет тот, который вы пишете для себя (оно того стоит).

Я использовал BluePrint и YUI, но меня всегда разочаровывают некоторые имена, которые они дают своим идентификаторам и классам.

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

Обязательно используйте хорошее соглашение об именах, на всякий случай, если кто-то еще придет, чтобы отредактировать CSS, тогда они будут иметь хорошее представление о том, к чему относится каждое имя стиля.

Я не использовал его, да, но я думаю, что эмастический может быть хорошей альтернативой, которую стоит проверить. он похож на blueprint в области видимости, но также поддерживает эластичные макеты (отсюда и название), и вы можете указывать значения в px, em или% и даже смешивать их.

Компас - это реальный фреймворк CSS в том смысле, что он предоставляет вам не только шаблоны (как YUI, так и blueprint), но также многоразовые конструкции и объявления более высокого уровня, но при этом дает вам знакомый синтаксис CSS.

Хорошую ссылку нашла: 12 лучших CSS-фреймворков и их понимание

Вот мое сообщение в блоге о CSS Frameworks Когда использовать фреймворк CSS?

Зачем использовать css 'frameworks'?

• Если вам не хватает времени.

• Если вы не знаете css и не знаете знаю кого-нибудь, кто может написать это для ты.

• Если ты не слишком дорожишь стандарты и т. д.

Я знаю программистов, которые были действительно счастливы использовать blueprint или 960, поскольку он позволяет им создавать макет самостоятельно, не обращаясь к фронтенд-разработчику. Это идеально подходит для личных проектов или стартапов с ограниченными ресурсами.

Если у вас уже есть приличное знание CSS, то, вероятно, у вас уже есть приличная библиотека стандартных макетов, поэтому вам явно не понадобится фреймворк.

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

Сказав все это, многие фреймворки из коробки действительно используют ужасные имена классов и т. д. Я знаю некоторые веб-сайты, которые взяли фреймворк в качестве отправной точки, а затем настроили его с помощью своих собственных тегов class и id. Но очевидно, что и с этим переписыванием нужно немного поработать. Использование чего-то вроде Compass, как упоминалось выше, действительно помогает обойти это.

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

Единственный известный мне способ использовать фреймворк CSS и сохранить семантическую разметку - это использовать абстракцию более высокого уровня. На данный момент Compass - единственный, о котором я знаю, достаточно зрелый для использования, но Николь Салливан, похоже, делает кое-что интересное в своем проекте «Object-Oriented CSS».

Я считаю, что умное использование примесей Sass в Compass является блестящим достижением и большим шагом к Святому Граалю поддерживаемой семантической разметки. Я не думаю, что я хотел бы использовать фреймворк, такой как Blueprint или YUI, без абстракции, такой как Compass, чтобы классы представления не попадали в разметку.

Кстати, есть красивый CSS-фреймворк под названием Elastic, который выглядит достаточно хорошо, и я подумываю добавить его в Compass.

Компас считаю потрясающим. Убедитесь, что вы видите скринкаст.

Я использую 960.gs для нескольких веб-сайтов и считаю его очень простым и легким, и оно того стоит. Экономит мне много работы по верстке. Обязательно проверьте настраиваемый генератор CSS, который имеет фиксированную ширину 960 пикселей.

Вы должны спросить себя, насколько эффективны доступные фреймворки для решения ваших проблем. Отвечают ли они вашим требованиям?

Используя фреймворк, вы можете установить некоторые правила или детали на уровне пикселей, а остальное время посвятить реализации и производству. Это огромный рост производительности. Если вы обнаружите, что тратите время на корректировку вещей на несколько пикселей в конце проекта (микроуправление дизайном), это признак того, что фреймворк может быть полезен.

Совет № 17 в Прагматичный программист говорит: «Программируйте близко к проблемной области». Использование уровня абстракции может приблизить вас к решению реальных проблем макета. Например: вы могли бы сконцентрироваться на улучшении взаимодействия с пользователем с дополнительным временем, которое у вас есть, а не с незначительной настройкой пикселей.

Это не означает, что вы должны жертвовать качеством ради количества. Дело в эффективности.

В недавнем проекте я создал свой собственный фреймворк, потому что у нас были очень ограниченные ресурсы, а популярные фреймворки не делали того, что я хотел. Затем я настроил PSD команды дизайнеров для привязки к той же сетке, которую я развернул.

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

Я думаю, что это видео-презентация генерального директора Site Point Кевина Янка ответит на ваш вопрос. Очень рекомендую его посмотреть.

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

Я поражен так называемыми «экспертами по CSS», которые критикуют эти инструменты, даже не вникая в них и не используя их. Они необходимы? Нет. Если вам нравится ваш собственный фреймворк (у вас ведь есть собственный фреймворк, не так ли? CSS-фреймворк - это просто тщательно определенная библиотека - каждый должен его использовать), то непременно продолжайте его использовать. Никто не заставляет вас использовать другие фреймворки, и я не вижу людей, которые используют фреймворки, говорящие пуристам CSS, что они «делают это неправильно».

Критика фреймворков с такой точки зрения показывает не только невежество, но и незащищенность. Например, смехотворно мнение, что человек будет использовать такой инструмент, как Compass, не зная CSS. Вы ведь понимаете, что фреймворк обычно не пишет за вас весь CSS? Вы все еще можете выйти и написать свой собственный CSS в контексте большинства фреймворков. Фактически, если вы не знаете CSS, вы можете быстро разочароваться.

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

проверьте http://www.ez-css.org/. один из самых простых и легких фреймворков css для работы. :)

Крейг,

Compass - это то, что вы ищете: он позволяет вам переименовывать классы CSS Blueprint, например, span-24, с вашими собственными именами. Он также расширяет функциональность CSS с помощью переменных и миксинов. Действительно, те, кто преждевременно судит о фреймворках, не проверив Compass, «упускают суть». Это похоже на людей, которые много лет назад сказали нам, что мы упускаем из виду суть, используя CSS вместо HTML-таблиц для наших макетов.

-Матт

Взгляните на эту демонстрацию: http://www.richstyle.org/demo-web.php Этот фреймворк основан на идее, что «HTML-тегов должно быть достаточно». Я считаю, что возможность повторного использования является наиболее важным фактором при выборе программного компонента, включая веб-фреймворк. Для разработчиков веб-фреймворков, чем больше вы придерживаетесь стандартов, тем больше вы гарантируете возможность повторного использования.