Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 174
Иногда для проверки быстрее
<span style="color:blue">, чем править сам файл стилей. Особенно это актуально в работе с Firebug.
Вы продаете душу дьяволу.
заведите себе в reset.css специальный класс debug
И в файербаге, динамически подключайте его.
debug {
border: 1px solid red;
background: blue;
}
И в файербаге, динамически подключайте его.
Я в Драгонфлае просто меняю CSS тому элементу, с которым работаю, а затем копирую результат в CSS-файл.
Лучше
не будет добавляться пикселей в высоту/ширину (:
outline: 1px solid red;не будет добавляться пикселей в высоту/ширину (:
Посмотрите на «A HANDY CSS DEBUGGING SNIPPET»:
http://homepage.mac.com/chrispage/iblog/C42511381/E20060806095030/index.html
http://homepage.mac.com/chrispage/iblog/C42511381/E20060806095030/index.html
Аха, слышал, более того: habrahabr.ru/blogs/css/65009/
Советую:
.debug-mode * { outline: 2px dotted red !important; }
.debug-mode * * { outline: 2px dotted green !important; }
.debug-mode * * * { outline: 2px dotted orange !important; }
.debug-mode * * * * { outline: 2px dotted blue !important; }
.debug-mode * * * * * { outline: 1px solid red !important; }
.debug-mode * * * * * * { outline: 1px solid green !important; }
.debug-mode * * * * * * * { outline: 1px solid orange !important; }
.debug-mode * * * * * * * * { outline: 1px solid blue !important; }
Для проверки чего? Не могу представить, почему такое написать быстрее, чем просто поправить файл стилей.
Обычно если меняется, то меняется внешний вид какого-то логического блока на уже размеченной странице. Если вы вдруг решили какой-то текст раскрасить в синий и у вас для этого текста нету отдельного идентификатора, например,
Стоит доразметить страницу, добавив тех логических тегов, которых не хватает и тогда для проверки будет быстрее править файл стилей. Особенно учитывая тот факт, что:
1. Не придётся писать столько лишних символов
2. Свойство применится сразу ко всем элементам и будет видно, как преображается страница.
И чем лучше
Обычно если меняется, то меняется внешний вид какого-то логического блока на уже размеченной странице. Если вы вдруг решили какой-то текст раскрасить в синий и у вас для этого текста нету отдельного идентификатора, например,
[class=note] — значит что-то с вашей версткой(по крайней мере с этим отдельным куском) не так.Стоит доразметить страницу, добавив тех логических тегов, которых не хватает и тогда для проверки будет быстрее править файл стилей. Особенно учитывая тот факт, что:
1. Не придётся писать столько лишних символов
2. Свойство применится сразу ко всем элементам и будет видно, как преображается страница.
И чем лучше
<span style="color:blue"> чем <font color="blue"> в данном случае?
В работе с Firebug достаточно ничего вообще не менять, а просто временно добавить новое CSS правило к выбраному html элементу.
Я бы сказал так: при работе с Firebug бывает удобно прописать стиль элемента, который автоматически заносится в style.
Поскольку это нужно только для того, чтобы подобрать нужные стили, и время жизни таких страниц — до обновления страницы, то данных подход вполне себя оправдывает.
Если же прописывать style в файлах — это уже темная сторона, тут безоговорочно.
Поскольку это нужно только для того, чтобы подобрать нужные стили, и время жизни таких страниц — до обновления страницы, то данных подход вполне себя оправдывает.
Если же прописывать style в файлах — это уже темная сторона, тут безоговорочно.
Кажется, в статье обсуждается вёрстка, а не дебаг.
Вы написали много текста. Девяносто процентов котогоро — преамбула к предпоследнему абзацу.
Сейчас мало кто сомневается, что тег font является признаком плохого кода. Гораздо больше заблуждений вызывают css-фреймворки. Даже использование SASS и Less не гарантирует уход от оных. Этому-то и нужно было и посвятить бòльшую часть статьи.
Сейчас мало кто сомневается, что тег font является признаком плохого кода. Гораздо больше заблуждений вызывают css-фреймворки. Даже использование SASS и Less не гарантирует уход от оных. Этому-то и нужно было и посвятить бòльшую часть статьи.
Про это написано много раз, но для большинства
А мысль про css-фреймворки без всего, что шло до неё — недостаточно понятна. Тем более, что до сих пор есть очень много новичков, которые только входят в эту область, пусть для них будет коротенький ликбез, чтобы они понимали, в чём суть семантичного html.
<font color="*"> — это просто невалидный тег, вместо которого надо применять <span style="color:*">. Хорошо, что вы это понимаете, но на самом деле большинству до этого далеко. Не до следования стандартам, а до осознания того, почему эти стандарты утверждают именно так.А мысль про css-фреймворки без всего, что шло до неё — недостаточно понятна. Тем более, что до сих пор есть очень много новичков, которые только входят в эту область, пусть для них будет коротенький ликбез, чтобы они понимали, в чём суть семантичного html.
Зато по качеству верстки можно смело судить о компетентности компании, ибо вариант с «историческими механизмами», довольно часто можно видеть в руках студентов однодневок, а проф тру верстка — солидным компаниям, которые экономят траффик и на верстке страницы тоже (как-то видел пример верстки, в котором было показано как сэкономить 20кб у страницы, что на 10 000 онлайн уже ощущается, что упоминается в пункте 4 преимуществ). Правда это не всегда так, но если уж наследили — то основательно. Также, качество верстки может быть использовании при рассмотрении кандидата на замещение вакансии. А почему нет?
Когда я впервые столкнулся с css-фреймворками, я подумал, что это такой способ реализации табличной вёрстки div-ами. Закрыл сайт со статьёй и больше никогда не возвращался к таким фреймворкам.
Очевидно, что подобные фреймворки удобны чисто верстальщикам, которых не волнует, как будет натягиваться верстка. У них задача — скопировать картинку и перенести ее в верстку предварительно порезав где надо. А остальное — это уже не их ума дело. Им за это на фрилансе не доплачивают…
а не верстальщикам ли потом с этим работать?
1) Если брать фриланс — то нет.
2) Во многих компаниях видел такую картину: Верстальщики верстуют и отдают программерам. А программеры плюются и переверстывают в процессе натяжки.
Я не говорю что всегда так. Но бывает. Часто.
2) Во многих компаниях видел такую картину: Верстальщики верстуют и отдают программерам. А программеры плюются и переверстывают в процессе натяжки.
Я не говорю что всегда так. Но бывает. Часто.
ну так надо или уволить недостаточно профессиональных верстальщиков, или научить их делать правильно ;)
=) А никто и не спорит, что с такими лучше не работать )))) Но сторону фриланса — не уволишь, а заказчи и понятия не имеет про то, а как же надо правильно верстать. Он только видит макет и результат. Со стороны компании — тут уже другой вопрос и другая философия )
Если компания заказывает вёрстку фрилансеру, то в ней должен быть человек, который грамотно сформулирует верстальщику задание, чтоб тот подобными фреймворками не баловался. Если компанию такие вещи не колышут, то они сами себе злобные буратины.
Если заказчик — один человек, которого вообще мало волнует как там верстальщик это сделает, то таки да, мучаться с такой вёрсткой будет следующий фрилансер. И если у него есть хоть капля мозгов, он заказчику объяснит что тут почём.
Если заказчик — один человек, которого вообще мало волнует как там верстальщик это сделает, то таки да, мучаться с такой вёрсткой будет следующий фрилансер. И если у него есть хоть капля мозгов, он заказчику объяснит что тут почём.
О да, на старой работе тоже не раз сталкивался с п. 2.
Причем отдавали обычно действительно сверстанное не пойми для чего, подобно примеру с CSS фреймворками. Руководство искренне верило, что дело верстальщиков сверстать и показать что шаблон в браузере нормально выглядит, а остальное дело программистов.
Вот и переверстывали потом после них почти все заново, благо время за натягивание дизайна оплачивалось.
Причем отдавали обычно действительно сверстанное не пойми для чего, подобно примеру с CSS фреймворками. Руководство искренне верило, что дело верстальщиков сверстать и показать что шаблон в браузере нормально выглядит, а остальное дело программистов.
Вот и переверстывали потом после них почти все заново, благо время за натягивание дизайна оплачивалось.
Подтверждаю, история частая.
Особенно когда с используемым программным framework'ом нельзя сделать некоторых вещей, которые сделаны в верстке.
Особенно когда с используемым программным framework'ом нельзя сделать некоторых вещей, которые сделаны в верстке.
Может просто надо было один раз обсудить с верстальщиками в каком именно виде нужна верстка?
Вам рассказать, что такое причастие?
>которых не волнует, как будет натягиваться верстка.
Сужает круг всех верстальщиков дл верстальщиков «которых не волнует, как будет натягиваться верстка.»
>которых не волнует, как будет натягиваться верстка.
Сужает круг всех верстальщиков дл верстальщиков «которых не волнует, как будет натягиваться верстка.»
Если вы работаете с людьми, которые делают работу через жопу, то тут ничего не сделаешь.
Верстальщик-фрилансер должен думать, что, как минимум, к нему больше не обратится этот клиент, если его команда программистов будет плеватся на верстку.
Конечно, всегда есть быдлокодеры, которым насрать, как это всё поддерживать. Ну так это не значит, что best practice в оформлении html+css кода — это плохо.
Верстальщик-фрилансер должен думать, что, как минимум, к нему больше не обратится этот клиент, если его команда программистов будет плеватся на верстку.
Конечно, всегда есть быдлокодеры, которым насрать, как это всё поддерживать. Ну так это не значит, что best practice в оформлении html+css кода — это плохо.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
При грамотном подходе того кто натягивает вопросы верстки вообще не должны волновать.
А уж использовался или нет фреймворк — подавно.
А уж использовался или нет фреймворк — подавно.
Как так не должны волновать? Любой макет можно сверстать так, что хрен натянешь)
Мне часто при верстке приходится думать, а как это сверстать так, чтобы программисты потом не парились (т.к. сам программист). А некоторые не думают, и тогда ппц.
Мне часто при верстке приходится думать, а как это сверстать так, чтобы программисты потом не парились (т.к. сам программист). А некоторые не думают, и тогда ппц.
При грамотном подходе ...Вы делаете правильно, что думаете. Это целиком задача верстальщика. Программист программирует, а не переверстывает.
Проблема в том, что обычно косяки верстки становятся заметны, когда в макет попадают реальные данные. Что ж, надо было указывать в задании дизайнеру не только сверстать по PSD один-в-один, но и всю возможную динамику данных. Либо отправлять на доработку (переверстывать опять же должен не программист).
Как правило верстальщики и программисты работают в тесной связке, поэтому проблемы переверстывания программистом при натягивании возникать не должно.
Я всегда предвижу возможную динамику данных и задю уточняющие вопросы. Кстати, так и не понял, что вы имели в виду:
При грамотном подходе того кто натягивает вопросы верстки вообще не должны волновать.«Натягивает» вроде программист. Какой бы ни был грамотный программист, если ему дали хреновую верстку, он не сможет ее натянуть.
Имел в виду, что программист не должен писать (или редактировать) самостоятельно ни одного тега в коде и уж тем более лазить в стили. Все это (html + css) уже должно быть готово и поправлено при необходимости. Программист вставляет вывод данных и только. Я бы еще заменил слово «натягивает» на «одевает», т.к. оно лучше отражает описываемый мной процесс.
Чтоб не было намеков на капитана, напомню, что я комментировал вот это:
Чтоб не было намеков на капитана, напомню, что я комментировал вот это:
Очевидно, что подобные фреймворки удобны чисто верстальщикам, которых не волнует, как будет натягиваться верстка.И суть комментария в том, что фреймворки могут использоваться не только криворукими верстальщиками, но и вполне вменяемыми, которые их используют как тщательно подобранный и значительно упрощающий жизнь инструмент.
А если вы имели в виду, что грамотным должен быть верстальщик, то это и капитану известно.
В моей терминологии эти люди называются нарезчиками, ибо в до-CSS-ные времена процесс назывался «нарезка». Кто просто картинку в HTML режет, тот занимается нарезкой и зовётся нарежчиком. А кто делает HTML вёрстку согласно ТЗ, а потом лепит к нему CSS исходя из картинки от дизайнера, тот занимается вёрсткой и зовётся верстальщиком.
Это мой IMHO, вот.
Это мой IMHO, вот.
Почему вас комбинированный вариант не устраивает:
Все равно в сложной верстке часто приходится блоки добавлять только ради дизайна или поддержки разнообразных браузеров. Простой пример: в тексте надо сделать стилями выравнивание картинок по правому и левому краю, как вы тут содержание от представления отделите? Или многоколоночная верстка, от 3 колонок.
<div class="best span-8 last"></div>
Все равно в сложной верстке часто приходится блоки добавлять только ради дизайна или поддержки разнообразных браузеров. Простой пример: в тексте надо сделать стилями выравнивание картинок по правому и левому краю, как вы тут содержание от представления отделите? Или многоколоночная верстка, от 3 колонок.
Классные у тебя запятые с начала строки.
А, главное, в тему! Или вы считаете, что не отделить запятую от кода (который на самом деле является частью предложения) было бы правильнее?)
CSS-фреймворки — отличный инструмент в грамотных руках, и я не вижу в них ничего плохого в их использовании. Если верстальщик понимает устройство фреймворка, у него не возникнет трудностей с версткой и дальнейшей натяжкой. А при работе с типовыми макетами, время, необходимое для их верстки, существенно сократиться.
В них нет ничего плохого, если процесс идет просто: дизайн — верстка — сведение в шаблоны — завершение проекта.
Но как только появляется интерактивность в процессе разработки, они становятся злом.
Если вдруг «Необходимо сделать этот блок вдвое шире» — вам придется править и css файл и файл разметки.
Реальность такова, что все меняется — и сайты тоже. Если при помощи семантики возведен слой абстракции между содержанием и оформлением, то любые изменения проводить проще.
Но как только появляется интерактивность в процессе разработки, они становятся злом.
Если вдруг «Необходимо сделать этот блок вдвое шире» — вам придется править и css файл и файл разметки.
Реальность такова, что все меняется — и сайты тоже. Если при помощи семантики возведен слой абстракции между содержанием и оформлением, то любые изменения проводить проще.
Я не призываю использовать css-фреймворки везде, просто не нужно их пропагандировать как что-то плохое. Фреймворк — инструмент, решающий определенную задачу — предоставить верстальщику готовую структуру страницы.
Я так и не понял, почему css-фреймворк становится злом. Если нужно сделать блок вдвое шире, то вместо класса span-5 я напишу span-10 (в blueprint).
И потом, не забывайте, что css-фреймворк нужен по сути только для базовой сетки, а поверх вы натягиваете свои стили. Получается двухуровневая структура: сетка на основе фреймворка, которую можно удобно и безболезненно перестраивать и ваши стили поверх нее.
Как здание: несущая опора и облицовка.
И потом, не забывайте, что css-фреймворк нужен по сути только для базовой сетки, а поверх вы натягиваете свои стили. Получается двухуровневая структура: сетка на основе фреймворка, которую можно удобно и безболезненно перестраивать и ваши стили поверх нее.
Как здание: несущая опора и облицовка.
Класс вы меняете в HTML, а должны менять CSS.
Обычно приходит ворох заданий на изменение: поменять ширину, сделать шрифт поменьше, чуть-чуть изменить цвет. И тут вам уже приходится «ползать» по двум совершенно разным файлам.
Я был бы только рад, если бы можно было писать как-то так:
#content extends .col10{
/* css rules */
}
Вот в этом случае css фреймворки не были бы злом.
Обычно приходит ворох заданий на изменение: поменять ширину, сделать шрифт поменьше, чуть-чуть изменить цвет. И тут вам уже приходится «ползать» по двум совершенно разным файлам.
Я был бы только рад, если бы можно было писать как-то так:
#content extends .col10{
/* css rules */
}
Вот в этом случае css фреймворки не были бы злом.
можно)
LessCSS:
Пользуюсь им и ни грамма не жалею.
.ad-block {
.information-block;
.corners(4px);
.box-shadow(#c00);
color: red;
text-decoration: blink;
}
Пользуюсь им и ни грамма не жалею.
Растолкуйте про LessCSS: чем компилится исходный css-код? Это, я понимаю, гем для руби? В руби я не бум-бум, может ли использовать LessCSS php-шник или потоновод?
Сижу сейчас, читаю доки ;) Похоже, за пару часов можно прикрутить к Ant, а значит можно будет спокойно использовать на любом сайте: хоть PHP, хоть Питон, хоть голый HTML.
использую в KohanaPHP без проблем. Писал свой плагин на базе LessPHP. Вот у меня оно выглядит так:
return array (
'files' => array (
APPPATH . 'files/admin.less' => PUBLICPATH . 'files/admin.css',
APPPATH . 'files/styles.less' => PUBLICPATH . 'files/styles.css'
)
);
Между прочим, для Нетбинса есть плагин с более-менее внятной подсветкой lesscss.
Костыли тоже инструмент. И, кроме шуток, полезный инструмент. Однажды мне пришлось ими пользоваться. И, тем не менее, второго раза мне не хочется, почему-то.
Мне, например, не охото заморачиваться на вёрстку и нет возможности нанять профессионального верстальщика. Поэтому лишь CSS фреймворки и спасают — можно быстро сделать вёрстку и начать кодить… Но в целом, я вас понимаю :) Но реальность другая.
Думаю стоит смотреть на HTML более широко. Большое количество сайтов делается дилетантами, без всяких там северных скриптов (php, perl) и бла бла бла, что и дало интернету такую популярность. Им плевать какая там у кого нагрузка они даже не забивают себе этим голову. Задача передать информацию в массы, а не показать логичный код. Конечно же стоит согласиться с автором, что в серьезных проектах над которыми работают профессионалы этого допускать не стоит, но для блондинок <fоnt color=«red»> тру, для создания хомяка не стоит читать историю W3C и вникать в тонкости разработки, надо просто сделать страничку и html со своими </fоnt>, </б>, </и>. Это как ехать на машине на работу и участвовать в серьезных гонках, гонщик всегда будет считать обычного водителя лохом, но обывателей больше.
ИМХО ))
ИМХО ))
Честно я не понимаю кому удобен вариант с гридами. Я попытался сделать один сайт на нем и решил больше не связываться. По моему ничем не лучше чем старая табличная верстка.
По поводу чистоты кода. Не получается. Бедность работы с размерами и привязкой, различные баги или расхождения в браузерах ( и нет хотя бы одного идеального :) — все фигачат иногда такое что заплатки приходиться вешать или переверстывать ) порождают чудовища контейнеров, да и то какое-нить выравнивание по нижнему краю и сверху ложиться js…
Остается одна надежда на то что веб активно проникает туда куда его не просили — на десктоп, в системы управления. И будет нам счастье когда-нить :)
По поводу чистоты кода. Не получается. Бедность работы с размерами и привязкой, различные баги или расхождения в браузерах ( и нет хотя бы одного идеального :) — все фигачат иногда такое что заплатки приходиться вешать или переверстывать ) порождают чудовища контейнеров, да и то какое-нить выравнивание по нижнему краю и сверху ложиться js…
Остается одна надежда на то что веб активно проникает туда куда его не просили — на десктоп, в системы управления. И будет нам счастье когда-нить :)
Фреймворки, имхо, бывают удобны, когда надо сначала быстро раскидать элементы. А потом все равно надо переверстывать в приличный вид.
Категоричный пиар div-верски приводит к тому, что дивы используют там где нужно и не нужно, а потом нужно в чужом css чтото поменять, даже Firebug иногда не помогает, так как еще любят использовать всякие хаки и извраты.
У меня бывали случаи, когда необходимо было для множества элементов указать различные размеры ширины: 110px, 52px, 75px, 20px, 66px, 45px и т.д. Причем они причем принадлежали одному классу и отличались только размером.
Как бы я не хотел следовать стандартам, но я предпочел использовать более понятную запись для моих элементов style=«width: Npx».
Другое бы выглядело ужаснее, множество классов со странными именами (а как столько имен придумать?), содержащие только ширину.
Для стороннего разработчика мне кажется было бы приятнее наблюдать размер именно в html коде, как я и сделал.
Как бы я не хотел следовать стандартам, но я предпочел использовать более понятную запись для моих элементов style=«width: Npx».
Другое бы выглядело ужаснее, множество классов со странными именами (а как столько имен придумать?), содержащие только ширину.
Для стороннего разработчика мне кажется было бы приятнее наблюдать размер именно в html коде, как я и сделал.
Согласен. Реальный пример: верстка результатов голосования (как на хабре). Имхо нет смысла не использовать динамический width у полосок.
У меня бывали случаи, когда необходимо было для множества элементов указать различные размеры ширины: 110px, 52px, 75px, 20px, 66px, 45px и т.д. Причем они причем принадлежали одному классу и отличались только размером.
А почему так? Наверняка, была какая-то причина, почему надо было сделать именно так. Вот можете вы её назвать? И почему бы не вынести это название в класс? Зато следующему программисту будет удобнее — он поймёт, почему вы так сделали по названию класса, а не будет ламать себе голову, почему тут у вас этот блок 20 пикселей, а там — 110.
По идее, вынесение стилей в css, это как вынесение повторяющегося кода в отдельный метод.
Но когда стиль маленький(только ширина, например) и используется только 1 раз, только в этом месте, и никогда и нигде больше, смысла выносить его в общий css, наверное, нету (как вариант). Единственный смысл, что этот кусочек css не закешируется, но при минимальных стилях (только ширина например) это, наверное, не столь критично.
И иногда, стиль в html, маленький стиль, экономит время, не надо лазить по файлам со стилями, и искать конкретный стиль в этом файле.
А вот если это стиль h2, который должен быть на все сайте один и тот же, то тогда надо конечно выносить.
В общем на мой взгляд, как нельзя везде использовать только дивы, так и не стоит все и всегда выносить в css.
Но когда стиль маленький(только ширина, например) и используется только 1 раз, только в этом месте, и никогда и нигде больше, смысла выносить его в общий css, наверное, нету (как вариант). Единственный смысл, что этот кусочек css не закешируется, но при минимальных стилях (только ширина например) это, наверное, не столь критично.
И иногда, стиль в html, маленький стиль, экономит время, не надо лазить по файлам со стилями, и искать конкретный стиль в этом файле.
А вот если это стиль h2, который должен быть на все сайте один и тот же, то тогда надо конечно выносить.
В общем на мой взгляд, как нельзя везде использовать только дивы, так и не стоит все и всегда выносить в css.
В html-файле мы описываем только логическую часть документа и ничего из оформления (да-да, это именно то, о чём мечтали те старые пердуны из W3C). Оформление ложится полностью на плечи css.
К сожалению, это неправда. Зачастую, чтобы сделать более-менее вменяемое оформление средствами одного только CSS, приходится городить бессмысленные div'ы и span'ы. Виной тому недостаточная мощность CSS в смысле задания относительного расположения элементов страницы. Кроме того, приходится использовать подмножество фич, имеющихся в CSS, т.к. браузеры поддерживают не всё или некорректно. Пусть те, у кого не было подобного рода проблем, скажем, с выстраиванием картинок с подписями в ряд, бросят в меня камень.
Поддерживаю.
Для простого случая, приведенного в статье («Представим, что один дизайн будет очень похож на тот, что есть, а другой будет с навигацией слева, а правая боковая панель уйдёт вниз. И он будет в тёмных цветах, а не светлых, как сейчас.») конечно работает.
Но в большинстве случаев для смены дизайна приходится как минимум добавлять дополнительные элементы. Т.е. получаем тоже, что в случае со «span-8» (возможно в гораздо меньшей степени, но все же).
Пусть даже дополнительные блоки, порожденные требованиями нового варианта оформления, не влияют на отображение старых, все равно получаем неприятность в виде наличия лишних элементов.
Для простого случая, приведенного в статье («Представим, что один дизайн будет очень похож на тот, что есть, а другой будет с навигацией слева, а правая боковая панель уйдёт вниз. И он будет в тёмных цветах, а не светлых, как сейчас.») конечно работает.
Но в большинстве случаев для смены дизайна приходится как минимум добавлять дополнительные элементы. Т.е. получаем тоже, что в случае со «span-8» (возможно в гораздо меньшей степени, но все же).
Пусть даже дополнительные блоки, порожденные требованиями нового варианта оформления, не влияют на отображение старых, все равно получаем неприятность в виде наличия лишних элементов.
Т.е. получаем тоже, что в случае со «span-8» (возможно в гораздо меньшей степени, но все же).
Согласна, в реальной ситуации часто бывает, что приходится вносить незначительные правки в контект, потому я и написала об этом в статье:
К сожалению, кое-какие причуды верстки не получится сделать без вмешательства в контент, но просто постарайтесь этого избежать, зная, что это категорически неправильно.
Но всё-равно, я считаю, что раз мы поставили маленькую кляксочку в тетради — это еще не причина заливать чернилом весь листок.
Семантически это не таблица, а галерея картинок.
По вашей логике любые данные так или иначе можно подвести под таблицу.
По вашей логике любые данные так или иначе можно подвести под таблицу.
Это ваше право, но таблицы предназначены для табличных данных, в вашем примере табличных данных нет.
Плюс подумайте о программистах которые будут натягивать вашу верстку, куда проще написать
for ($i=0;$i<$n;$i++) {
$result.='<div class='image-item'></div>';
}
чем парсить нелинейный табличных код
<table>
<tr><td><img /></td><td><img /></td>
<tr><td><img /></td><td><img /></td>
</table>
А если не 2 столбца а 3 нужно будет сделать? всю функцию менять.
Плюс подумайте о программистах которые будут натягивать вашу верстку, куда проще написать
for ($i=0;$i<$n;$i++) {
$result.='<div class='image-item'></div>';
}
чем парсить нелинейный табличных код
<table>
<tr><td><img /></td><td><img /></td>
<tr><td><img /></td><td><img /></td>
</table>
А если не 2 столбца а 3 нужно будет сделать? всю функцию менять.
Более того, такую галерею было бы удобно делать без определенного количества по ширине в случае с резиновой вёрсткой.
То есть, на телефоне это будет одна колонка в ширину, на нетбуке — 3 колонки, а на экране шириной в 2000 пикселей — 10 колонок.
То есть, на телефоне это будет одна колонка в ширину, на нетбуке — 3 колонки, а на экране шириной в 2000 пикселей — 10 колонок.
Див — это такой елемент, семантика которого задаётся через класс/айди.
С помощью википедии вывел свое теоретическое видение о том, что такое таблица.
en.wikipedia.org/wiki/Table_%28database%29:
en.wikipedia.org/wiki/Table_%28information%29
То есть таблица — это когда все столбцы объедены общей чертой (например, это может быть столбец «размер», или столбец «цвет»), а каждая ячейка стобца — это значение для соответсвующей строки.
Почему таблица не подходит для галереи изображений? потому что в галерее изображений нету rows и columns по идеологии (разве что, если один столбец — это картинка, другой — описание).
С помощью википедии вывел свое теоретическое видение о том, что такое таблица.
en.wikipedia.org/wiki/Table_%28database%29:
table is a set of data elements (values) that is organized using a model of vertical columns (which are identified by their name) and horizontal rows. A table has a specified number of columns, but can have any number of rows. Each row is identified by the values appearing in a particular column subset which has been identified as a candidate key.
en.wikipedia.org/wiki/Table_%28information%29
A table consists of an ordered arrangement of rows and columns. This is a simplified description of the most basic kind of table. Certain considerations follow from this simplified description:
То есть таблица — это когда все столбцы объедены общей чертой (например, это может быть столбец «размер», или столбец «цвет»), а каждая ячейка стобца — это значение для соответсвующей строки.
Почему таблица не подходит для галереи изображений? потому что в галерее изображений нету rows и columns по идеологии (разве что, если один столбец — это картинка, другой — описание).
Возможно вы правы, но что вы подразумеваете под табличными данными? Желательно привести не пример, а обобщенное определение в вашем понимании.
Хотя вы спрашивали не меня, но, тем не менее, я ответил именно, что подразумеваю под табличными данными. не утверждаю, что это общепринятое определение, но, думаю, большинство имеют именно это ввиду.
Я не знаю как объяснить, но когда видишь контент, то сразу становится понятно что из контента таблица а что нет, могу сказать что таблицы в хорошей для оформления не используются вообще, для контента достаточно редко, именно для данных которые в виде таблицы (подобие таблиц экселя), из графики в таблицах за исключением очень редких случаев могут быть только маленькие иконки.
Нет, картинки — это не табличные данные. Например, список юзеров (логин, дата регистрации, чего-ещё-придумаете) можно расположить в виде таблицы (с заголовком и данными). Или оборотная ведомость — это тоже таблица (заголовок, данные, группировка по товарам, датам и т.п и футер). А вот картинки с подписями — не таблица ни разу. Особенно, когда неизвестно заранее, сколько картинок нужно разместить в одном ряду. Тем более, что картинки с подписями — это всего лишь пример. Могу и другие привести. Скажем, blockquote с нарисованными аккуратными кавычками-ёлочками слева вверху и справа внизу.
Когда я вставляю 10.000-й div со своим уникальным именем, чтоб он не пересекся ни с одним другим дивом проекта, не унаследовал ничего сверху, и ничего не покорежил снизу, начинаю сомневаться, что это прям такая гениальная методика. Да, в целом статья правильная, но уж больно радужно описывает ситуацию в мире верстки.
Ок, если у нас проект на 3 страницы все пучком — «error», «menu», etc… А если на много страниц то мы получаем имена вида: «film-details-unknown-device-error-5» и прописываем им аж одно свойство — color:red. И только не надо мне рассказывать про наследование / каскадирование, гораздо проще прописать то, что тебе надо и быть спокойным за судьбу дива, чем обнулять паддинги, марджины, убирать обводочки и пр., то, что осталось в наследство от изначального «error».
Ок, если у нас проект на 3 страницы все пучком — «error», «menu», etc… А если на много страниц то мы получаем имена вида: «film-details-unknown-device-error-5» и прописываем им аж одно свойство — color:red. И только не надо мне рассказывать про наследование / каскадирование, гораздо проще прописать то, что тебе надо и быть спокойным за судьбу дива, чем обнулять паддинги, марджины, убирать обводочки и пр., то, что осталось в наследство от изначального «error».
никто не мешает пойти по пути Google и Yandex, и имена такие хранить только на сервере, а клиенту отдавать сжатые стили с именами вида .fde
можно подробнее?
>У нас пока есть только github.com/gfranco/jeanny
>
>Ну и зачатки bem-фреймворка в котором это будет by design: github.com/bem
— clubs.ya.ru/bem/
>
>Ну и зачатки bem-фреймворка в котором это будет by design: github.com/bem
— clubs.ya.ru/bem/
Как верстать красиво или чем плохи css-фреймворкиНазвание какое-то бессмысленное получается, если честно. Прочитав его, я сделал вывод, что использование фреймворков = некрасивая верстка. Прочитав текст и проявив немного дедукции скорректировал: использование фреймворков = верстальщик с кривыми руками.
А это не так.
Указанные css-фреймворки, как и всё другое, обладают своими плюсами и минусами. Красивая, более простая и страндартизированная верстка — это как раз одно из преимуществ фреймворков. Помимо этого верстальщик как правило получает reset, улучшение типографики, оптимизацию для печати, оформление форм и их элементов управления и многое другое.
Да, в сеточных фреймворках, появляется частичное смешение содержимого и представления. Но это на совести того, кто выбирает подходящее для решения конкретной задачи средство разработки. Если минусы фреймворка не критичны, верстальщик экономит кучу времени и получает более логичный результат. Понятное дело, что фремворк не стоит брать на борт, когда в первую очередь важны производительность и возможность координальной смены оформления.
Закончу тем, что любой фреймворк является велосипедом. Каждый сам выбирает использовать его или нет.
автора статьи, имхо, больше волнует семантика в веб, нежели использование фреймворков. По сути у каждого опытного верстальщика уже есть какое-то подобие фреймворка для себя, набора инструментов с которого он начинает каждый проект. И не обязательно это будут подобные сетки вроде span-8… Хотя и тут момент спорный — хороший дизайн всегда привязан к модульной сетке, почему бы не реализовать ее в верстке?
в те далёкие времена был только хтмл. потом появился цсс. потом у тебя по всей видимости провал в памяти — ты до сих пор живёшь в мире 10-летней давности. а он изменился. если раньше всё делали на чистом хтмл, то сейчас повсеместно применяют шаблонизаторы — они обладают куда большими возможностями повторного использования кода. использование их на клиенте позволяет так же добиться минимального размера страницы. но при этом не ограничивает нас мистическими блоками :before и :after, а позволяет создавать реальные блоки.
представим на секунду что мы потеряли css где-то на рубеже веков, а остался у нас только xslt. по пунктам:
1. исходный xml не загромождён классами — нету никаких [div class=«important»]. вместо них простые и логичные [habr:important].
2. мы не повторяем описание оформления несколько раз — для каждого тэга мы пишем шаблон только один раз.
3. пользователь также может использовать любые разрешённые нами тэги. например [habr:cut]. и ему не придётся заботиться о том, чтобы вставить дополнительную вмл-ину для ие, чтобы были скруглённые уголки
4. вёрстка получается минимально возможной, а шаблоны кэшируются.
5. ссылка на набор шаблонов прописывается в одном месте и также можно один набор менять на другой лёгким движением руки.
6. в принципе тоже реализуемо, но через задницу
7. то же что и 5
так чем же плоха запись Так почему же плоха запись [font color=«red»]? да ничем. единственный минус — при отладке придётся копаться в каше презентационных тэгов. но xbl изящно решает и эту проблему. помимо кучи других, типа инициализации по мере загрузки элементов, расширения дом-модери и прочих. к сожалению работает он только в мозилле и остальные как-то не торопятся его реализовывать. все заняты прикручиванием к хтмл тэгов header и aside, а также нагромождением css в духе css-layout.
представим на секунду что мы потеряли css где-то на рубеже веков, а остался у нас только xslt. по пунктам:
1. исходный xml не загромождён классами — нету никаких [div class=«important»]. вместо них простые и логичные [habr:important].
2. мы не повторяем описание оформления несколько раз — для каждого тэга мы пишем шаблон только один раз.
3. пользователь также может использовать любые разрешённые нами тэги. например [habr:cut]. и ему не придётся заботиться о том, чтобы вставить дополнительную вмл-ину для ие, чтобы были скруглённые уголки
4. вёрстка получается минимально возможной, а шаблоны кэшируются.
5. ссылка на набор шаблонов прописывается в одном месте и также можно один набор менять на другой лёгким движением руки.
6. в принципе тоже реализуемо, но через задницу
7. то же что и 5
так чем же плоха запись Так почему же плоха запись [font color=«red»]? да ничем. единственный минус — при отладке придётся копаться в каше презентационных тэгов. но xbl изящно решает и эту проблему. помимо кучи других, типа инициализации по мере загрузки элементов, расширения дом-модери и прочих. к сожалению работает он только в мозилле и остальные как-то не торопятся его реализовывать. все заняты прикручиванием к хтмл тэгов header и aside, а также нагромождением css в духе css-layout.
сАйтИКи доЛжнЫ быТь пРивлЕКаТЕльНЫМи
Тут тоже отдельный класс для каждого символа? Если «это» напишется только раз только на одной странице? Статья классная, но так категорично я бы не утверждал.
Тут тоже отдельный класс для каждого символа? Если «это» напишется только раз только на одной странице? Статья классная, но так категорично я бы не утверждал.
Просто надо пользоваться compass-style.org/docs/ и проблем не будет.
В Compass нет перечисленных здесь проблем + он настолько удобен и гибок, что попробовав 1 раз уже никогда не откажешься от него.
В Compass нет перечисленных здесь проблем + он настолько удобен и гибок, что попробовав 1 раз уже никогда не откажешься от него.
спасибо, мне, как начинающему верстальщику, очень не хватало подобного разьяснения, что хорошо, что плохо и почему. А комментарии некоторые вообще бесценны.
Всё правильно, двумя руками «за».
Мои 5 копеек про то, почему CSS-фреймворки — это плохая идея: pepelsbey.net/2008/04/css-frameworks/
Мои 5 копеек про то, почему CSS-фреймворки — это плохая идея: pepelsbey.net/2008/04/css-frameworks/
Цсс-фреймворки(в частности гридовые) — отличная альтернатива табличной верстке. Да, они и отступают от принципов семантичной верстки, да, навязывают свою систему имен для класснеймов, но они позволяют быстро и однозначно оформить документ.
Цсс-фреймворк хорош только в том случае, если ты сам его написал под свои нужды.
Ааа, как так можно?
На и так банально простую вещь использовать фреймоврки.
Далее пойдет
xhml framework, html4.0 framework.
Попахивает бредом маненько.
На и так банально простую вещь использовать фреймоврки.
Далее пойдет
xhml framework, html4.0 framework.
Попахивает бредом маненько.
Не следует искать семантику там, где ее нет.
Сетка сайта семантики зачастую не имеет, это просто места где будет находиться что-то. Контентные блоки, к примеру.
Контентные блоки имеют семантику, тут все верно.
Придумывать сетке сайта семантичные названия — занятие неблагодарное. Я говорю о сайтах больших, сложных. К примеру — cnn.com/
960.gs — это фреймворк для сетки сайта.
Не стоит нападать на инструменты — если не знаете для чего они были сделаны.
Сетка сайта семантики зачастую не имеет, это просто места где будет находиться что-то. Контентные блоки, к примеру.
Контентные блоки имеют семантику, тут все верно.
Придумывать сетке сайта семантичные названия — занятие неблагодарное. Я говорю о сайтах больших, сложных. К примеру — cnn.com/
960.gs — это фреймворк для сетки сайта.
Не стоит нападать на инструменты — если не знаете для чего они были сделаны.
А где же в Вашем примере семантика?
Давайте до конца:
1. Логотип так ли нужен в виде img?
2.
3.
4.
Давайте до конца:
1. Логотип так ли нужен в виде img?
2.
<li>Nutochka</li><li>выйти</li>— смешали теплое с мягким
3.
<nav><ul>— дешевле
<ul id='nav'>
4.
<li><span>посты</span></li>— зря ссылку убрали
Говорю, как автор фреймворка ( https://launchpad.net/invisible ): они хороши для прототипов. Если клиент хочет посмотреть, как будет выглядеть сайдбар шириной 30%, а контент 70%, а что будет, если 25% и 75%, а что будет, если сайдбар слева, а не справа… Просто поменял пару классов в HTML и все.
lessframework.com хорош не только для этого, кстати.
lessframework.com хорош не только для этого, кстати.
Подскажите как воспользоваться штуками типа LessCss и SASS тому кто знаком лишь с PHP? Нашел https://github.com/pornel/CSS-Preprocessor — но не поддерживает вложенные конструкции :(
Покажите пожалуйста пример проекта где css на 100% отделен от html. Я видел только один пример, и там за годы работы и «динамичности» нарос такой слой «старых» стилей, что разобраться в этом без толстого мануала было очень сложно.
Пока только разбираюсь с семантикой html5, но, на мой взгляд, разметка секции «article» и «aside» получились немного не так, как задумывалось в спецификации html5. В секции «article» вполне можно использовать элемент «footer», вместо которого используется велосипед на "{Article.tags}{Article.footer}". В секции «aside» идут вполне законченные блоки, которые подразумевают из себя «nav», ибо блоки содержат в себе набор ссылок, вместо чего используется "" (и почему не id=«best»?).
Когда можно будет сверстать две колонки, не вырвав себе на жопе все волосы, то тогда, и только тогда можно начинать говорить о вреде фреймворков и какой-то там семантике.
Какое отношение колонки имеют к семантике? Это чисто визуальный трюк.
Прямое. То, что их невозможно сделать, не наворотив два-три уровня ненужных div'ов — как раз то, на что жалуется автор, говоря, что фреймворки — плохо.
Автор, насколько я понял, жалуется на то, что авторы не используют уже имеющиеся элементы и ради «сеточки» крутят дополнительные уровни вложенности с совершенно абстрактными именами классов.
Семантика — это не «верстать всё на списках», это когда человек понимает что он делает: использование элементов по назначению, правильное и осмысленное именование, минимум экстра-разметки. Даже упомянутый сегодня CSS Zen Garden оставляет в конце шаблона пучок элементов для оформительских целей. Но не просто «элементов», а именно стерильных:
Семантика — это не «верстать всё на списках», это когда человек понимает что он делает: использование элементов по назначению, правильное и осмысленное именование, минимум экстра-разметки. Даже упомянутый сегодня CSS Zen Garden оставляет в конце шаблона пучок элементов для оформительских целей. Но не просто «элементов», а именно стерильных:
<div> и <span> — в полном соответствии с языком.Семантика — это как раз использование div'ов для div'ов, span'ов для span'ов, section'ов для section'ов и т.п.
Так вот, пока нет вменяемого, человеческого, способа даже две колонки рядом поставить без наворачинвания дивов одного над другим, ни о каком «понимает что он делает: использование элементов по назначению, правильное и осмысленное именование, минимум экстра-разметки.» речи идти не может.
Верстальщик был бы только рад вместо трех уровней div'ов написать один — но низзя :)
А с своем комментарии выше я просто криво выразился. Автор сетует на вот ти все уровни вложенности, но в реальном мире без них нельзя.
Так вот, пока нет вменяемого, человеческого, способа даже две колонки рядом поставить без наворачинвания дивов одного над другим, ни о каком «понимает что он делает: использование элементов по назначению, правильное и осмысленное именование, минимум экстра-разметки.» речи идти не может.
Верстальщик был бы только рад вместо трех уровней div'ов написать один — но низзя :)
А с своем комментарии выше я просто криво выразился. Автор сетует на вот ти все уровни вложенности, но в реальном мире без них нельзя.
я не могу вас понять. в чём проблема с двуми и даже тремя колониками?
Предлагаю сделать что-нибудь типа главной страницы erlanger.ru/ без div'ов, которые не имеют отношение к семантике. Но это — простой пример.
Предлагаю сделать просто какой-нибудь трех-колоночный layout, а потом сделать его liquid. Но — внимание! — используя только семантическую верстку. Без этих всяких div#wrap и div#outer-wrap и т.п.
Предлагаю сделать просто какой-нибудь трех-колоночный layout, а потом сделать его liquid. Но — внимание! — используя только семантическую верстку. Без этих всяких div#wrap и div#outer-wrap и т.п.
эээ. и в чём проблема?
может, у меня что-то не то с компьютером, но не вижу никаких проблем.
Вперед, сделайте. Я хочу на это посмотреть
freecr.ru/erlanger/ вот. в ie не проверял (у меня линукс), но должно работать.
можете использовать под lgpl, раз профессионального верстальщика нету ;)
можете использовать под lgpl, раз профессионального верстальщика нету ;)
использовал float где? inline-block, говорят, баговый в ie. хотя и есть способы заставить работать его, но у меня нету ИЕ, чтобы тестировать, потому использую float, так как уверен, что в любом браузере результат будет выглядеть одинаково.
Красиво, не спорю. Хотя без одного несемантического элемента (div#overall) все равно не обошлось.
Но, как я сказал, erlanger.ru — это простой вариант, да еще прибитый гвоздями к пикселям. Шаг вправо-влево, все, приплыли.
Но, как я сказал, erlanger.ru — это простой вариант, да еще прибитый гвоздями к пикселям. Шаг вправо-влево, все, приплыли.
Я считаю div#overall вполне семантическим. Но, раз вы настаиваете, переделал без него. Это не проблема.
Не знаю. У меня таких пробле никогда нету. На любой вёрстке. Вот недавно делал сайт, у которого обе колонки должны быть одинаковой высоты. И работать должен во всех браузерах. Без проблем.
Не знаю. У меня таких пробле никогда нету. На любой вёрстке. Вот недавно делал сайт, у которого обе колонки должны быть одинаковой высоты. И работать должен во всех браузерах. Без проблем.
ссылка: freecr.ru/erlanger/
А чем по вашему мнению название класса footer(взято из примера) хуже названия класса showgrid или append.
Что .footer вы будете прибивать к низу или располагать в самом низу, что grid.css из blueprint за вас вносит правила позиционирования блоков с определенными классами. Только правила эти написаны за вас и оттестированы огромным сообществом, а не 2-3 менеджерами, в лучшем случае тестерами неопределенной квалификации.
Требования к разметке в blueprint вполне вменяемые, имхо. Но в вашем примере тоже ul зачем-то завернуты в дополнительный див, когда можно задать стили для самого ul, если гнаться за минимизацией разметки.
Я и сам фреймворками не пользуюсь. Не нравится громоздкий css файл и ограничения. Хотя, вроде для fluid макетов что-то там обещали изобрести, но я особо не слежу. Просто у вас доводы высосаны из пальца, имхо. Кстати, по поводу начала статьи. «Hyper Text», как раз таки, и означает «больше, чем текст» :)
Ну, и в сравнении табличной и блочной разметки я не заметил роли css особой…
Что .footer вы будете прибивать к низу или располагать в самом низу, что grid.css из blueprint за вас вносит правила позиционирования блоков с определенными классами. Только правила эти написаны за вас и оттестированы огромным сообществом, а не 2-3 менеджерами, в лучшем случае тестерами неопределенной квалификации.
Требования к разметке в blueprint вполне вменяемые, имхо. Но в вашем примере тоже ul зачем-то завернуты в дополнительный див, когда можно задать стили для самого ul, если гнаться за минимизацией разметки.
Я и сам фреймворками не пользуюсь. Не нравится громоздкий css файл и ограничения. Хотя, вроде для fluid макетов что-то там обещали изобрести, но я особо не слежу. Просто у вас доводы высосаны из пальца, имхо. Кстати, по поводу начала статьи. «Hyper Text», как раз таки, и означает «больше, чем текст» :)
Ну, и в сравнении табличной и блочной разметки я не заметил роли css особой…
Имхо, если макет сразу рассчитывался на сетку (960gs например) или можно выявить часто повторяющиеся закономерности расположения блоков — css-фрейворк в виде сетки должен использоваться. Если пытаться привязать фреймворк к случайному макету, выйдет слишком «дорого» и верстка будет нестабильной.
да-да, давайте же перестанем пользоваться фреймворками, каждый должен иметь свой велосипед в котором заблудится другой. тем самым мы становимся незаменимыми для компании.
фреймворки это не самый лучший способ разработки. но он оптимален в учётом поддержки, кустомизации, ловли багов и т.д. и т.п.
фреймворки это не самый лучший способ разработки. но он оптимален в учётом поддержки, кустомизации, ловли багов и т.д. и т.п.
А у меня свой фреймворк, с блекджеком. Я в нём понимаю всё.
вот потому ты незаменимый, в нём понимаешь только ты.
видимо, таких на хабре больше, не ты страну назвали индией
видимо, таких на хабре больше, не ты страну назвали индией
Вы занимаетесь демагогией. А на самом деле — просто троллите.
>>заискивание у народа
посмотрись в зеркало, ты написал что фреймворки зло, это девиз джуниоров, которые неспособны освоить более-менее сложный инструмент. учитывая современную аудиторию хабра, это популистский ход. заглянув в твой профиль становится понятно, что ты пишешь то, что пипл хавает, результаты тоже на лицо.
нормальные же специалисты знают о плюсах фреймворков, самым важным из которых являются стандарты и договоренности, делающие код легко поддерживаемым. любой велосипедостроитель приходит к своему собственному фреймворку, который, за очень редким исключением, хуже и уже инструментов, поддерживаемых сообществом, а главное непонятен постороннему человеку.
далее вы умолчали, что фреймворк — это лишь каркас, никто не мешает добавить свои классы с более семантичными именами.
и финальный фокус с подменой понятий, когда вместо css фреймворка вы приводите фреймворк для создания *сетки*. вот первая ссылка из моего гугла css-framework.ru/doc/utilites/, заметь наличие семантики.
— итог, нахватавшись по верхам и не вникнув в суть, вы делаете неверные «экспертные» выводы. я бы вам посоветовал всё же познакомиться с css фреймворками, но не буду, потому что меня тошнит от местных обычаев прикрывать свою недолёкость в вопросах за громким словом «тролль».
и да, я сам штампую свои фреймворки, для набивания руки и проверки идей, но прекрасно понимаю, какое это зло в серьёзных проектах, лишь исключительные проекты не могут найти подходящего фреймворка и тогда их пишут исключительные люди с многолетним опытом.
посмотрись в зеркало, ты написал что фреймворки зло, это девиз джуниоров, которые неспособны освоить более-менее сложный инструмент. учитывая современную аудиторию хабра, это популистский ход. заглянув в твой профиль становится понятно, что ты пишешь то, что пипл хавает, результаты тоже на лицо.
нормальные же специалисты знают о плюсах фреймворков, самым важным из которых являются стандарты и договоренности, делающие код легко поддерживаемым. любой велосипедостроитель приходит к своему собственному фреймворку, который, за очень редким исключением, хуже и уже инструментов, поддерживаемых сообществом, а главное непонятен постороннему человеку.
далее вы умолчали, что фреймворк — это лишь каркас, никто не мешает добавить свои классы с более семантичными именами.
и финальный фокус с подменой понятий, когда вместо css фреймворка вы приводите фреймворк для создания *сетки*. вот первая ссылка из моего гугла css-framework.ru/doc/utilites/, заметь наличие семантики.
— итог, нахватавшись по верхам и не вникнув в суть, вы делаете неверные «экспертные» выводы. я бы вам посоветовал всё же познакомиться с css фреймворками, но не буду, потому что меня тошнит от местных обычаев прикрывать свою недолёкость в вопросах за громким словом «тролль».
и да, я сам штампую свои фреймворки, для набивания руки и проверки идей, но прекрасно понимаю, какое это зло в серьёзных проектах, лишь исключительные проекты не могут найти подходящего фреймворка и тогда их пишут исключительные люди с многолетним опытом.
ты написал что фреймворки зло, это девиз джуниоров, которые неспособны освоить более-менее сложный инструмент.
Более-менее сложный инструмент? Не смешите меня. Потыкать в кнопочки и написать в трёх местах
class="grid_12" — офигенно сложно разобраться. Есть более-менее сложные технологии, но css-фреймворки к ним совершенно не относятся.твой профиль становится понятно, что ты пишешь то, что пипл хавает, результаты тоже на лицо.
Пипл хавает юмор, статьи про гаджеты и грустные истории про то, какая жопа в рашке. Я пишу вещи, которые интересны узкому кругу людей.
вот первая ссылка из моего гугла css-framework.ru/doc/utilites/, заметь наличие семантики.
В этом примере не больше семантики, чем в первом сайте Василия Пупкина. .no-margin — это семантический класс? или .img-repl? вам надо разобраться, что такое семантика, чтобы не позориться.
А теперь разберем ваше сообщение, которое сплошь пропитанно демагогией
ты написал что фреймворки зло
Подмена тезиса. Я писал, что css-фреймворки в том виде, в котором они сейчас есть(а не фреймворки впринципе) зло. Я за фреймворки впринципе (например, люблю KohanaPHP) и если бы были css-фреймворки, которые не имели недостатков blueprint и 960gs — я был бы рад.
ты написал что фреймворки зло, это девиз джуниоров
Апеляция к очевидности. Никаких подтверждающих фактов, что это девиз джуниоров — нету.
это девиз джуниоров, [...] учитывая современную аудиторию хабра, это популистский ход.
Ошибочные силлогизмы и софизмы. Т.к. высказывание «фреймворки — зло» — это девиз джуниоров, значит высказывание «существующие css-фреймворки — зло» — это популистичный ход? у вас плохо с логическими цепочками.
Весь второй абзац — Апелляция к очевидности, ложная авторитетность. Кто такие «нормальніе специалисты»? кто такой «велосипедостроитель»? почему фреймворк «велостроителя» должен быть непонятен постороннему человеку?
далее вы умолчали, что фреймворк — это лишь каркас, никто не мешает добавить свои классы с более семантичными именами.
Манипулирование смыслом высказываний. Вы стараетесь сказать (убедить кого-то?) этим предложением, что css-фреймворки могут быть семантичными, если ввести паралельно фреймворку семантичные имена. Но, наличие семантичных тегов не означает отстутвие несемантичных тегов.
и финальный фокус с подменой понятий, когда вместо css фреймворка вы приводите фреймворк для создания *сетки*
Подмена тезиса. Во-первых, я не приводил никаких фреймворков.
Но допустим, вы имели ввиду, что я согласен с автором топика, которая привела примеры 960gs и blueprint (предположение верное).
Следовательно, вы стараетесь создать впечатление, что 960gs и blueprint — это не css-фреймворки, а
фреймворк для создания *сетки*
Тем не менее, согласно, например, списку css-фреймворков — они есть фреймворками.
Более того, вы делаете ложное заявление (возможно, в силу незнания, возможно в попытке ввести в заблуждение читающего ваше сообщение), что примеры из css-framework.ru/doc/utilites/ содержат семантику.
ксожалению не могу соревноваться в скорости и количестве постинга
семантика вот
фреймворк используется в качестве помощника, который убирает различия и неприятное поведение браузеров, а разработчик лишь занимается размещением и оформлением элементов. Для сеток же на совести точное позиционирование.
Подмена тезиса. Ты упорно приводишь grid, а не css фреймворки, даже в названии которых присутствует их назначение.
Апеляция к очевидности. Опытный специалист уже имел дело с фреймворками и использует их либо сторонние, либо свои наработки. Лишь новичёк может не обладать освоенным каркасом для разработки. От того что называешь правду правдой она не должна стать ложью.
Ошибочные силлогизмы и софизмы. Смотри выше, ты не описываешь существующие CSS фреймворки. Я лишь сократил «существующие css-фреймворки» до фреймворки, а не переврал их назначение.
Апелляция к очевидности, ложная авторитетность. Правда есть правда. Велосипед перестает быть велосипедом после того, как им начинают пользоваться другие разработчики, обычно появляется документация. В этот момент он уже становится существующим фреймворком.
Манипулирование смыслом высказываний. Ну, здесь вы постарались с фантазиями, я и не утверждал что фреймворк помогает достичь 100% семантичности, нельзя этого сделать с текущим html. И даже не утверждаю что это нужно.
Подмена тезиса. Микроскоп инструмент, молоток инструмент, микроскопом плохо забивать гвозди, инструменты не годятся для забивания гвоздей ??? вот так вы перевернули всё.
960 grid system — grid говорит сам за себя
Blueprint — print говорит само за себя, css фреймворк для печати и типографии.
и в конце вы зациклились вернувшись к первому обвинению, хотя я нигде не писал, что ФРЕЙМВОРК обеспечивает семантику и что он ОБЯЗАН это делать, фреймворк должен упрощать разработку и поддержку.
Вы пытаете доказать мой троллизм, а не опровергнуть утверждения? Если у существо серой окраски с коротким хвостом и большими ушами, то это не обязательно слон, может быть и заайцем. Читаю я много, а не увлекаюсь демогогией. И спорю не для того, чтобы доказать неправоту другого, а чтобы убедиться в своей правоте.
семантика вот
фреймворк используется в качестве помощника, который убирает различия и неприятное поведение браузеров, а разработчик лишь занимается размещением и оформлением элементов. Для сеток же на совести точное позиционирование.
Подмена тезиса. Ты упорно приводишь grid, а не css фреймворки, даже в названии которых присутствует их назначение.
Апеляция к очевидности. Опытный специалист уже имел дело с фреймворками и использует их либо сторонние, либо свои наработки. Лишь новичёк может не обладать освоенным каркасом для разработки. От того что называешь правду правдой она не должна стать ложью.
Ошибочные силлогизмы и софизмы. Смотри выше, ты не описываешь существующие CSS фреймворки. Я лишь сократил «существующие css-фреймворки» до фреймворки, а не переврал их назначение.
Апелляция к очевидности, ложная авторитетность. Правда есть правда. Велосипед перестает быть велосипедом после того, как им начинают пользоваться другие разработчики, обычно появляется документация. В этот момент он уже становится существующим фреймворком.
Манипулирование смыслом высказываний. Ну, здесь вы постарались с фантазиями, я и не утверждал что фреймворк помогает достичь 100% семантичности, нельзя этого сделать с текущим html. И даже не утверждаю что это нужно.
Подмена тезиса. Микроскоп инструмент, молоток инструмент, микроскопом плохо забивать гвозди, инструменты не годятся для забивания гвоздей ??? вот так вы перевернули всё.
960 grid system — grid говорит сам за себя
Blueprint — print говорит само за себя, css фреймворк для печати и типографии.
и в конце вы зациклились вернувшись к первому обвинению, хотя я нигде не писал, что ФРЕЙМВОРК обеспечивает семантику и что он ОБЯЗАН это делать, фреймворк должен упрощать разработку и поддержку.
Вы пытаете доказать мой троллизм, а не опровергнуть утверждения? Если у существо серой окраски с коротким хвостом и большими ушами, то это не обязательно слон, может быть и заайцем. Читаю я много, а не увлекаюсь демогогией. И спорю не для того, чтобы доказать неправоту другого, а чтобы убедиться в своей правоте.
я понимаю, отрицательный рейтинг и ограничение на постинг раз в час, ничего страшного.
хорошо. допустим, вы действительно хотите вынести из этого разговора чего-нибудь полезное. учтите, если вы хотите исключительно «убедиться в своей правоте», то есть вам все-равно на мнение окружающих, то предупредите сразу. если вы хотите выслушать мои аргументы, привести свои аргументы и сделать выводы — с удовольствием продолжу беседу.
судя по вашему комментарию, вы не совсем понимаете мою мысль. я не против только grid-фреймворков. я осуждаю идеологию большинства современных css-фреймворков.
посмотрим, какие у нас есть типы фреймворков (по предназначению). Некоторые фреймворки могут совмещать в себе несколько типов:
1. reset. самый короткий вариант —
2. font-фреймворки, например Google Fonts Api. Тоже своего рода css-фрейморк. Ничего против не имею.
3. grid-фреймворки — уже обсудили
3. base-фреймворки — всякие базовые вещи, как .no-margin, .img-repl и .corners-10
пункт 2 и пункт 3 имеют приблизительно одну и ту же проблему.
вот давайте посмотрим на JQuery (обожаю этот фреймворк) и его UI.
отличное UI, подходящее для большинства мелких сайтов.
он базируется на хорошем, более-менее семантичном фреймворке.
конечно, не без недостатков, но, учитывая цели — вполне неплохо. посмотрите на класс .ui-corner-all, который в теме UI lightness выглядит так:
А теперь представим, что jqueryui решили пойти по пути css-framework, назвав этот класс .corner-4.
И вот я, пользователь jqueryui, делаю свой бложек. Со временем я понимаю, что круглые уголки не вписываются в мой дизайн и меняю css:
Согласны, что получился феерический результат? Подход jquery, на самом деле тоже не без недостатков. Он обязывает меня использовать везде одинаковые уголки (а вдруг я хочу разные? — это можно сделать выйти за пределы фреймворка), но, согласен, там были причины так сделать.
Сам я не парюсь и использую что-то типа такой записи:
Как считаете, не лучше ли оно, чем те некоторые несемантичные и трудноподдерживаемые вещи, которые есть сейчас во многих обычных фреймворках?
хорошо. допустим, вы действительно хотите вынести из этого разговора чего-нибудь полезное. учтите, если вы хотите исключительно «убедиться в своей правоте», то есть вам все-равно на мнение окружающих, то предупредите сразу. если вы хотите выслушать мои аргументы, привести свои аргументы и сделать выводы — с удовольствием продолжу беседу.
судя по вашему комментарию, вы не совсем понимаете мою мысль. я не против только grid-фреймворков. я осуждаю идеологию большинства современных css-фреймворков.
посмотрим, какие у нас есть типы фреймворков (по предназначению). Некоторые фреймворки могут совмещать в себе несколько типов:
1. reset. самый короткий вариант —
* { margin : 0; padding : 0 }. Считаю очень удобным и пользуюсь всегда. Он вполне вписывается в идеологию CSS и HTML и не нарушает ни один из недостатков. Я пользуюсь вариантом от yui.2. font-фреймворки, например Google Fonts Api. Тоже своего рода css-фрейморк. Ничего против не имею.
3. grid-фреймворки — уже обсудили
3. base-фреймворки — всякие базовые вещи, как .no-margin, .img-repl и .corners-10
пункт 2 и пункт 3 имеют приблизительно одну и ту же проблему.
вот давайте посмотрим на JQuery (обожаю этот фреймворк) и его UI.
отличное UI, подходящее для большинства мелких сайтов.
он базируется на хорошем, более-менее семантичном фреймворке.
конечно, не без недостатков, но, учитывая цели — вполне неплохо. посмотрите на класс .ui-corner-all, который в теме UI lightness выглядит так:
.ui-corner-all {
-moz-border-radius: 4px;
-webkit-border-radius: 4px;
border-radius: 4px;
}
А теперь представим, что jqueryui решили пойти по пути css-framework, назвав этот класс .corner-4.
И вот я, пользователь jqueryui, делаю свой бложек. Со временем я понимаю, что круглые уголки не вписываются в мой дизайн и меняю css:
.corner-4 {
-moz-border-radius: 0;
-webkit-border-radius: 0;
border-radius: 0;
}
Согласны, что получился феерический результат? Подход jquery, на самом деле тоже не без недостатков. Он обязывает меня использовать везде одинаковые уголки (а вдруг я хочу разные? — это можно сделать выйти за пределы фреймворка), но, согласен, там были причины так сделать.
Сам я не парюсь и использую что-то типа такой записи:
.ad-block {
.information-block;
.corners(4px);
.box-shadow(#c00);
color: red;
text-decoration: blink;
}
Как считаете, не лучше ли оно, чем те некоторые несемантичные и трудноподдерживаемые вещи, которые есть сейчас во многих обычных фреймворках?
пункт 2 и пункт 3 имеют приблизительно одну и ту же проблему.
* пункт 3 и 4
теперь я понял отличие наших взглядов, вы хотите использовать фреймворки как основу и на нём выполнять задание. у меня подход несколько иной, более компонентный, я ожидаю от него помощь на сложных участках и отсутствие преград на сложных.
смена дизайна за счёт семантики в моей практике показал себя как утопический и принёс нам массу проблем и вестальщика, а проблемы после смены верстальщика усугубились. с тех пор у меня в проектах трёхуровневая иерархия шаблонов (только каркас html, «семантический» вариант с прописанными классами, шаблон проекта) из-за этой избыточности я избегаю оверворкинга и могу себе позволить проспать немного работу, уверенный что не сорвутся сроки.
смена дизайна за счёт семантики в моей практике показал себя как утопический и принёс нам массу проблем и вестальщика, а проблемы после смены верстальщика усугубились. с тех пор у меня в проектах трёхуровневая иерархия шаблонов (только каркас html, «семантический» вариант с прописанными классами, шаблон проекта) из-за этой избыточности я избегаю оверворкинга и могу себе позволить проспать немного работу, уверенный что не сорвутся сроки.
угу, только сразу надо прочитать МАНУАЛ, а затем у них возникает ситуация, затем когда возникает ситуация не описанная в мануале и вовсе наступает апокалипсис, потому что в чужом они не умеют разбираться.
насмотрелся я уже таких на форумах, которые даже мануал одолеть не могут дальше cookbook и затем лажают готовые решения на каждом углу.
про пипл хавает дальше развивать не буду, это был ответ на тролля, мои или ваши индивидуальные качества не должны влиять на аргументы.
насмотрелся я уже таких на форумах, которые даже мануал одолеть не могут дальше cookbook и затем лажают готовые решения на каждом углу.
про пипл хавает дальше развивать не буду, это был ответ на тролля, мои или ваши индивидуальные качества не должны влиять на аргументы.
На самом деле inline-стили часто появляются независимо от желания пользователя, например при использовании WYSWYG-редакторов. Тут фреймворки ни при чем
Была еще такая лекция яндекса bit.ly/dBqAkb о фреймворках.
Я с ними согласен, пытался изучать какой-то фреймворк, но понял — бессмысленно тратить время. Свой наработанный материал приятнее и понятнее. И цель быстрее достигается.
Я с ними согласен, пытался изучать какой-то фреймворк, но понял — бессмысленно тратить время. Свой наработанный материал приятнее и понятнее. И цель быстрее достигается.
Идите к нам работать.
статья хороша до пункта «css-фреймворки»
css-фреймворки нужны! особенно на крупных проектах/порталах
и их нужно писать самостоятельно, а не использовать готовые
css-фреймворки нужны! особенно на крупных проектах/порталах
и их нужно писать самостоятельно, а не использовать готовые
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как верстать красиво или чем плохи css-фреймворки