Читаючи на іншому форумі, я натрапив на світ CSS Frameworks. Я спеціально дивився на BluePrint . Мені було цікаво, чи хтось інший натрапив на рамки CSS, підкажіть, що найкраще і чи варто їх докладати?
Читаючи на іншому форумі, я натрапив на світ CSS Frameworks. Я спеціально дивився на 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 'фреймворки'?
Якщо ти тиснеш на час.
Якщо ви не знаєте css і не знаєте когось, хто може написати це за вас.
Якщо ви не надто дорого ставляться до стандартів тощо.
Я знаю програмістів, які були дуже раді використовувати план або 960, оскільки це дозволяє їм складати макет самостійно, не звертаючись до переднього розробника. Це ідеально підходить для особистих проектів або стартапів з обмеженими ресурсами.
Якщо ви вже маєте гідні знання CSS, то, імовірно, у вас вже є пристойна бібліотека макетів фондів, тому вам явно не знадобиться рамка.
Однак якщо ви новачок і вам просто потрібно щось запустити і працювати, ви можете звернутися до основи, оскільки це робить основний макет набагато простішим, а також вирішує сумісність браузера.
Сказавши все це, багато фреймворків поза полем використовують деякі жахливі назви класів і т. Д. Я знаю про деякі веб-сайти, які взяли основу як вихідну точку, а потім налаштували її під власні теги класу та id. Але очевидно, що в роботі над цим переписуванням теж небагато роботи. Використання чогось на зразок Компаса, як згадувалося вище, допомагає обійти це.
Отже, рамки CSS - вони можуть заощадити ваш час, ціною семантики. Вони також можуть зашкодити вашим знанням CSS, але це залежить від того, скільки ви інвестуєте в вивчення предмету взагалі. Чи будете ви ними користуватися, залежати від вас.
Вам доведеться запитати себе наскільки ефективні наявні рамки вирішують ваші проблеми. Чи відповідають вони вашим вимогам?
Використовуючи рамки, ви можете встановити деякі правила або деталі на рівні пікселів і присвятити решту свого часу на впровадження та створення. Це величезне підвищення продуктивності праці. Якщо ви потратите на час коригування речей на кілька пікселів пізно в проекті (мікроуправління дизайном), це знак того, що рамка може бути корисною.
Порада № 17 у програмі «Прагматичний програміст» говорить: «Програма близька до проблемного домену». Використання шару абстракції може наблизитись до вирішення реальних проблем компонування. Наприклад: ви, можливо, зможете зосередитись на покращенні користувальницької роботи з додатковим часом, ніж у незначних коригувань пікселів.
Це не означає, що ви повинні жертвувати якістю для кількості. Йдеться про ефективність.
На нещодавньому проекті я створив власну структуру, оскільки у нас були дуже обмежені ресурси, і популярні рамки не робили того, що я хотів. Потім я встановив PSD-команди команди дизайнерів, щоб переключитися на ту саму сітку, яку я розгорнув.
Рамка не повинна бути якоюсь конкретною реалізацією CSS. Це не повинно бути чимось роздутим, що ви завантажили з інтербету, чи щось реалізує застарілі ідеї. Це просто техніка отримання роботи. Я не здивуюсь, якщо деякі кодери вже мають власні рамки і навіть не знають цього. Насправді, якщо ви розглядаєте DOM як набір елементів за замовчуванням, які ви поширюєте за допомогою CSS, то це рамки за визначенням.
Я фактично витратив хорошу частину останніх 24 годин на дослідження самостійно, хе. Мій висновок полягав у тому, що приємний перезавантаження (я використав Reset YUI ), а можливо, щось інше, щоб встановити базові речі ( шрифти YUI були варті в моєму випадку; можливо, "додаткові смаколики" BluePrint були б у вашому) є хорошою ідеєю. Але "рамка" --- яка, як правило, є на зразок сітки YUI ---, є занадто обмежувальною, змушує вас використовувати їх імена класів, ідентифікатори тощо, і рідко вписується на ваш сайт, як це зроблено вручну CSS.
Отже, коротше: скидання здаються досить приємними; добре усунути всі зміни, наприклад, маргінал проти вкладки для списків, інтервал між абзацами чи будь-що інше. Але це настільки, наскільки я б взяв це.
Я думаю, що компас дивовижний. Переконайтеся, що ви бачите екранну трансляцію .
Я використовую 960.gs для кількох веб-сайтів і вважаю це дуже простим і простим і вартим зусиль. Економить мені багато роботи над компонуванням. Переконайтесь, що перевірте користувальницький генератор CSS, який відходить із фіксованою шириною 960 пікселів.
Я думаю, що ця відео-презентація генерального директора Site Point Кевіна Янка відповість на ваше запитання. Я дуже рекомендую переглянути його.
Компас дозволяє перейменовувати класи та ідентифікатори ваших фреймворків власними семантичними іменами, так що ви можете перевірити це. Він також забезпечує доступ до речей, які ви просто не отримуєте за допомогою звичайного ванільного CSS, такого як міксини.
Мене вражають так звані "експерти CSS", які критикують ці інструменти, не дійсно копаючись і використовуючи їх. Чи вони істотні? Ні. Якщо вам подобається ваш власний фреймворк (у вас є своя власна, правда? Рамка CSS - це лише ретельно визначена бібліотека - всі повинні використовувати її), то, будь-ласка, продовжуйте її використовувати. Ніхто не змушує вас використовувати інші фреймворки, і я не бачу людей, які використовують рамки, які кажуть пуристам CSS, що вони "роблять неправильно".
Критичні рамки з такої точки зору просто виявляють невпевненість, а також незнання. Наприклад, сміється думка, що людина використовує такий інструмент, як Компас, не знаючи CSS. Ви розумієте, правда, що рамки взагалі не записують всі ваші CSS для вас? Ви все ще можете виривати та писати свій власний CSS в контексті більшості фреймів. Насправді, якщо ви не знаєте CSS, ви можете швидко засмутитися.
Для себе я вдячний мати рамки, тому що це вже документально підтверджено, протестовано сотнями інших користувачів, і я можу застосовувати власні класи та ідентифікатори через Compass. Якщо мені потрібно щось, для чого не підходить фреймворк, я буду кодувати своє.
Метт Raible із слави AppFuse деякий час проводив конкурс CSS Framework, щоб розробити CSS фреймворки для AppFuse. Результати публікуються тут . Є кілька варіацій, і я використовував деякі, тому що я використовую AppFuse і вважаю їх дуже хорошими.
Варто додати, що ці CSS фреймворки працюють добре, оскільки вони використовуються в тематичних додатках. Тобто, якщо ви дотримуєтесь правил, то перехід від одного до іншого настільки ж просто, як і зміна одного значення у файлі властивостей.
Я використовував BluePrint з великим успіхом на сайті (я міг би згадати сайт тут, але я впевнений, що повідомлення буде позначено як спам!). Я не впевнений, чи буду використовувати його в майбутньому, хоча через те, що одна з ідей CSS, на яку я думав, не мала чітко закодованої логіки компонування. У вас не повинно бути елементів css під назвою span-24 та span-12 для визначення макету, але щось на кшталт searchBox та mainContent. Принаймні так я бачу.
Хороше посилання, яке я знайшов: Топ-12 рамок CSS та як їх зрозуміти
Ось моя публікація в блозі про CSS Frameworkworks Коли використовувати CSS Framework?
Єдиний спосіб, з якого я знаю, використовувати CSS-фреймворк і зберігати семантичну розмітку - це використовувати абстракцію вищого рівня. Наразі Компас - єдиний, кому я знаю, що достатньо зрілий для використання, але Ніколь Салліван, здається, займається цікавими речами зі своїм проектом "Об'єктно-орієнтований CSS".
Я вважаю розумне використання Міксом Міксом компасом Compass геніальним, і це великий крок до Священного Граалу, що має змогу досягти смислової розмітки. Я не думаю, що я не хотів би використовувати рамку типу Blueprint або YUI без абстракції, наприклад, Compass, щоб утримати класи презентацій поза розміткою.
До речі, є симпатична структура CSS під назвою Elastic, яка виглядає досить добре, що я розглядаю можливість додати її до Compass.
Я вважаю, що CSS - це простота. Мета полягає в тому, щоб мати одне або два місця для перевірки, коли ви посилаєтесь між HTML та таблицею стилів. Додавання більшої кількості рядків, а особливо рядків, які ви не написали і, ймовірно, не такі знайомі, буде експоненціально збільшувати складність, тим самим мінливість CSS-коду.
Я б запропонував ваші макети, коли ви пишете їх, і розробити з цього загальну систему шаблонів. Хоча я люблю робити CSS більш модульним, часто і залежно від дизайну, ваш CSS може бути дуже конкретним і зовсім не модульним.
Я використовував програму Blueprint на кількох разових сайтах, і це, безумовно, заощадило час, головним чином при тестуванні між браузерами.
Це, безумовно, відстійно, додаючи презентаційний код до своєї розмітки, хоча з яскравого боку він читабельний. Хоча я люблю концепцію "ви можете переробити дизайн, не торкаючись розмітки", якщо ви створюєте сайт, де це дійсно не відбудеться ніколи, і вам просто потрібно це зробити вчора, Blueprint - це щось, на що слід подивитися.
Існують також і компроміси в тому, які типи макетів можливо створити. Якщо ви будете каркасно розміщувати сайт із самого початку на суворій сітці, перенести його в рамки буде набагато легше, як мінімум суєти.
Я використовував BluePrint та YUI, але я завжди засмучуюся деякими іменами, які вони дають ідентифікатор та класи.
Кожен свій, але я вважаю за краще робити щось з нуля, але через деякий час ви розробляєте процес, в якому ви будете використовувати свою попередню роботу і застосовувати її до нових проектів, а також просто зробите кілька змін, щоб веб-сайт виглядав так, як ви подобається.
Не забудьте скористатися хорошою умовою іменування, на випадок, якщо хтось інший по дорозі прийде редагувати css, тоді вони матимуть гарне уявлення про те, на що посилається кожна назва стилю.
Крейг,
Компас - це те, що ви шукаєте: він дозволяє перейменовувати свої Blueprint CSS класи типу "span-24" власними іменами. Він також розширює функціонал CSS за допомогою змінних та mixins. Справді, ті, хто передчасно оцінює рамки, не перевіривши Компас, "не вистачає точки". Це схоже на тих людей, які нам років тому казали, що ми не вистачаємо точки, використовуючи CSS замість таблиць HTML для наших макетів.
-Мат
перевірити http://www.ez-css.org/ . одна з найпростіших і легких фреймворків css, над якою можна працювати. :)
Погляньте на цю демонстраційну версію: http://www.richstyle.org/demo-web.php Ця рамка заснована на ідеї, що "HTML тегів має бути достатньо". Я думаю, що повторне використання є найважливішим фактором вибору програмного компонента, включаючи веб-рамку. Що стосується розробників веб-рамок, то чим більше ви дотримуєтесь стандартів, тим більше ви гарантуєте повторне використання.