Готовим базовый стилевой файл
Вынужден констатировать, что на днях мне поступила очень серьезная претензия. Причем не без оснований.
Июнь 2009 года, обновлений все еще нет :(
Когда будут? Или ресурс умер?
Смею вас заверить, ресурс не умер. По крайней мере время от времени можно наблюдать заметное оживление на форуме. Ну а что касается очередного и столь длительного перерыва в повествовании – сегодня я постараюсь отчасти исправить сложившуюся ситуацию.
В предыдущей публикации мы подробно рассмотрели различные теоретические аспекты, касающиеся каскадных таблиц стилей. Теперь, как и было обещано ранее, мы приступаем к практическому занятию по созданию базового стилевого файла. Впоследствии, имея в своем распоряжении базовый HTML-документ и соответствующий CSS-файл, мы рассмотрим примеры верстки различных макетов.
Создаем CSS-файл
Первое, что нам необходимо сделать, – это непосредственно создать отдельный стилевой файл. Как и в случае с HTML-документом, для создания и редактирования CSS-файла я рекомендую вам воспользоваться каким-нибудь специальным редактором (Macromedia Dreamweaver, HomeSite) или «продвинутым» блокнотом Notepad++.
Давайте назовем наш базовый стилевой файл main.css и поместим его в отдельную папку, которую создадим рядом с нашим базовым HTML-документом. Поверьте, в отдельной папке CSS-файлу будет уютнее.
Кодировка CSS-файла в принципе может быть любой (в разумных пределах). Тем не менее, желательно, чтобы она соответствовала кодировке HTML-документа. По этой причине давайте сохраним наш стилевой файл в кодировке UTF-8 (о том, как задать или изменить кодировку символов в документе подробно рассказывается в статье про базовый HTML-документ).
Также будет совсем не лишним явно обозначить кодировку таблицы стилей непосредственно в ней самой. Это можно сделать при помощи специального правила @charset, которое должно располагаться в самом начале стилевого файла:
@charset "utf-8";
Некоторые инструменты веб-разработки (например, Macromedia Dreamweaver) при непосредственном изменении кодировки CSS-файлов добавляют данное правило автоматически.
Обнуление полей и отступов
Давайте теперь обратим внимание на принятую в CSS модель представления документа в виде прямоугольных областей – CSS Box Model. Данная модель подразумевает, что для каждого HTML-элемента в документе генерируется определенная прямоугольная область, которая называется «боксом» (box). Каждый такой бокс содержит область контента (content area), в которой находится непосредственное содержимое породившего бокс элемента (текст, графическое изображение и т.п.), а также может иметь несколько дополнительных областей, которые предназначаются для оформления отступов (paddings), границ (borders) и полей (margins) элемента.
Отступы, границы и поля элементов разделяются на верхние, правые, нижние и левые сегменты. В процессе верстки документов соответствующие этим сегментам CSS-свойства позволяют нам отодвигать элементы друг от друга, выравнивать элементы, обрамлять их различными рамками, а также решать множество других задач визуализации. Тем не менее, здесь и сейчас давайте пока остановимся лишь на том, что все эти отступы, границы и поля существуют. Только не просто существуют, но и имеют для многих структурных элементов определенные значения по умолчанию.
Все дело в том, что Спецификация CSS предписывает браузерам применять ко всем отображаемым документам так называемую «встроенную таблицу стилей», которая задает стандартное форматирование HTML-элементов. Само собой разумеется, любые пользовательские стилевые правила (например, наш базовый стилевой файл) имеют приоритет над стилевыми инструкциями по умолчанию и могут их успешно переопределять в соответствии с правилами каскадирования.
Если вы обратите внимание на рекомендуемый Спецификацией CSS образец таблицы стилей по умолчанию, вы сможете заметить, что элементу <body>…</body>, например, изначально предписывается иметь 8-пиксельные поля (margins), а элементам <ol>…</ol> и <ul>…</ul> – левое поле (margin-left) размером в 40 пикселей. Тем не менее, подобные рекомендации носят исключительно информативный характер. Как следствие, различные структурные элементы в разных браузерах по умолчанию имеют разные поля и отступы. К примеру, Internet Explorer вместо положенных 8-пиксельных полей для <body>…</body> назначает этому элементу margin: 15px 10px. Хотя, с другой стороны, этот браузер придерживается рекомендаций Спецификации в отношении элементов <ol>…</ol> и <ul>…</ul>, в то время как Firefox, Opera, Safari и Chrome (куда уж теперь без него) задают для этих элементов левый отступ (padding-left: 40px) вместо левого поля (margin-left: 40px).
К чему это все? А к тому, что одним из важнейших критериев качественной верстки является так называемая кроссбраузерность – одинаковое, максимально идентичное отображение сверстанных веб-страниц во всех современных браузерах. В контексте всего вышеизложенного становится очевидно, что без предварительного обнуления полей и отступов у всех HTML-элементов с целью последующего назначения элементам этих свойств «вручную» ни о какой кроссбраузерности не может быть и речи.
Без изначального обнуления полей и отступов для всех структурных элементов
вы никогда не добьетесь кроссбраузерности.
Другими словами, гораздо логичнее изначально обнулить все поля и отступы у всех HTML-элементов, чтобы впоследствии иметь возможность самому контролировать их величину, не опасаясь, что в разных браузерах эта величина может оказаться разной. Для реализации этой задачи прекрасно подходит универсальный селектор:
@charset "utf-8";
* {margin: 0px; padding: 0px;}
Само собой разумеется, добавлять единицу измерения к нулевым значениям свойств (например, px) совсем необязательно: ноль – он и есть ноль. В конечном итоге это просто дело вкуса.
Позвольте также обратить ваше внимание на тот факт, что использование универсального селектора для обнуления стандартных полей и отступов у элементов не обходит стороной и элементы управления (кнопки, переключатели, поля для ввода текста – все то, что обычно содержат интерактивные формы). Именно этот аспект зачастую порождает всякие маразматические предрассудки:
@charset "utf-8";
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {margin: 0px; padding: 0px;}
К сожалению, некоторые веб-разработчики до сих пор впадают в панику, когда дело доходит до «ручной» стилизации содержимого интерактивных форм. Именно они активно пропагандируют идею о том, что элементы управления якобы совершенно не имеют никакого отношения к дизайну. Не стоит им уподобляться. На сегодняшний день нет никаких причин, по которым нельзя было бы контролировать средствами CSS визуальное представление элементов управления в интерактивных формах. В ближайшем будущем этому вопросу обязательно будет посвящена отдельная публикация.
Фон документа
Как правило, визуальное расположение, а иногда и размеры боксов, порожденных определенными HTML-элементами, вычисляются относительно некоторых прямоугольных областей, которые называются контейнерами (containing block). Само собой разумеется, эти контейнеры появляются не из ниоткуда. В подавляющем большинстве случаев в качестве контейнеров для одних боксов выступают другие боксы, которые являются для первых родительскими или еще более «древними» предками. Таким образом, все порожденные HTML-элементами боксы формируют контейнеры для своих боксов-потомков по определенным правилам, которые мы обязательно рассмотрим в отдельной публикации, а здесь и сейчас давайте пока обратим внимание на элемент <html>…</html>, который является корневым элементом любого HTML-документа.
В первую очередь этот элемент отличается от любых других HTML-элементов тем, что у него нет родительского элемента. Именно по этой причине в роли контейнера для элемента <html>…</html> выступает так называемый начальный контейнер (initial containing block), который для большинства визуальных устройств вывода являет собой ничто иное как окно браузера.
Важной отличительной особенностью элемента <html>…</html> является поведение назначенного этому элементу фонового цвета или изображения (свойство background), а именно: назначенный элементу <html>…</html> фон как бы «изымается» из него и становится фоном окна браузера.
Заданный корневому элементу документа фон всегда распространяется
на все окно браузера с учетом возможного скроллинга
и вне зависимости от реальной ширины или высоты корневого элемента.
Это является довольно приятной возможностью, поскольку фоновые цвета и изображения других HTML-элементов обычно подобным образом себя не ведут.
Тем не менее, нельзя не отметить, что в старые, но отнюдь не добрые времена, когда все версталось исключительно с помощью таблиц, а каскадные таблицы стилей использовались только для управления шрифтами (если вообще использовались), фоном окна браузера считался фон элемента <body>…</body>. При этом мысль о том, что корневым элементом документа является все-таки элемент <html>…</html>, визуальное представление которого потенциально может контролироваться средствами CSS, никому даже не приходила в голову. Как следствие, из соображений обратной совместимости в Спецификации CSS недвусмысленно сказано:
For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element.
Если в двух словах, все сводится к тому, что в случае отсутствия у элемента <html>…</html> фонового цвета или изображения, фоном окна браузера должен считаться фон элемента <body>…</body>. При этом он должен вести себя аналогичным образом: «изыматься» из элемента <body>…</body> и распространяться на все окно браузера.
Тем не менее, я вам настоятельно не рекомендую задавать фон элементу <body>…</body>, пренебрегая возможностью назначить его элементу <html>…</html>. Первая и главная на то причина – одно из ключевых правил семантической верстки, согласно которому «не следует привносить в структурную разметку элементы <div>…</div> в оформительских целях». К сожалению, очень часто многие веб-разработчики забывают о возможности назначить фоновый цвет или изображение элементу <html>…</html>. Как следствие, в качестве фона окна браузера используется фон <body>…</body>, а в структурную разметку зачастую привносятся всякие лишние DIV-ы, без которых невозможно получить требуемое визуальное представление веб-страницы.
Кроме того, существует еще одна причина, по которой следует задавать фоновый цвет или изображение именно элементу <html>…</html>. Дело в том, что при отсутствии у элемента <html>…</html> какого-либо фона спозиционировать фон элемента <body>…</body> каким-либо хитрым образом уже не представляется возможным. Здесь речь идет не о фоновых изображениях и свойстве background-position, а примерно вот о каких стилевых инструкциях:
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {}
body {background: #CCCCFF; width: 800px; margin: 0px auto;}
При таком раскладе попытка выровнять по центру элемент <body>…</body> (вместе с заданным ему фоновым цветом) изначально обречена на провал: фон будет неизбежно распространяться на все окно браузера.
Давайте теперь сделаем то, к чему нас так долго подводили всякие теоретические аспекты – назначим фон элементу <html>…</html>. Пусть пока он будет белым. Так или иначе, ничто не помешает нам впоследствии изменить его на любой другой (в том числе и на графическое изображение). Главное сейчас – это чтобы он был. А какой именно – на данном этапе несущественно.
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
Единственное, о чем еще мне хотелось бы здесь упомянуть – так это о том, что там, где это возможно, фоновые цвета и изображения желательно задавать именно при помощи стенографического (обобщающего) свойства background, а не background-color или background-image. Тем самым мы, пусть незначительно, но все-таки сокращаем размер CSS-файла.
Типографские свойства
Как вам должно быть уже известно (в частности, из предыдущей публикации), многие свойства каскадных таблиц стилей могут наследоваться. В данном контексте было бы совсем неплохо задать где-нибудь в одном месте базовые значения для некоторых типографских CSS-свойств. Причем сделать это так, чтобы они наследовались подавляющим большинством структурных элементов документа.
Для решения этой задачи как нельзя лучше подходит элемент <body>…</body>, поскольку именно он является контейнером для всех логических конструкций HTML.
Свойство font-family
В первую очередь нам необходимо определиться с гарнитурой (типом шрифта), которая будет наследоваться большинством элементов-потомков контейнера <body>…</body>. Само собой разумеется, подобное наследование будет происходить только в том случае, если внешний вид шрифта для этих элементов не будет впоследствии явным образом переопределен.
Вообще со шрифтами во Всемирной паутине дела обстоят весьма непростым образом. С одной стороны, это обусловлено тем, что браузеры способны отображать только те гарнитуры шрифтов, которые установлены на компьютерах пользователей. При этом необходимо принимать во внимание тот факт, что разные операционные системы (Windows, Mac OS X, Linux Ubuntu и т.п.) комплектуются разными наборами шрифтов. На иллюстрации справа изображены некоторые относительно «безопасные» гарнитуры, которые в настоящее время обычно присутствуют как на платформах PC, так и на платформах Mac.
С другой стороны, ничто не мешает пользователям самостоятельно устанавливать на свои компьютеры новые шрифты, равно как и удалять ранее установленные гарнитуры (в том числе и те, которые поставляются в комплекте с операционными системами). Как следствие, никогда нельзя быть полностью уверенным, что указанная в таблице стилей гарнитура обязательно будет доступна на компьютере того или иного пользователя. Именно по этой причине CSS-свойство font-family, с помощью которого определяется внешний вид шрифта, может принимать несколько разных значений, которые указываются через запятую:
body {font-family: Georgia, "Times New Roman", Times, serif;}
В данном конкретном случае наиболее предпочтительным шрифтом для отображения содержимого документа будет являться Georgia. Если эта гарнитура по каким-то причинам не будет доступна в пользовательской системе, браузеры попытаются использовать вместо нее шрифт Times New Roman. В случае отсутствия на компьютере пользователя гарнитуры Times New Roman браузеры попытаются отобразить содержимое документа с использованием шрифта Times (данная гарнитура поставляется в комплекте с Mac OS X). Если же и Times не будет найден, для отображения содержимого документа будет использоваться установленный в системе шрифт, который указан в настройках браузеров как «шрифт с засечками (serif) по умолчанию».
При любом определении шрифтов настоятельно рекомендуется указывать в качестве
резервных гарнитур их общие семейства (serif, sans-serif, monospace, cursive).
В принципе, благодаря возможности определять резервные гарнитуры, в некоторых случаях можно не ограничиваться использованием только лишь «безопасных» шрифтов. Главное при этом – это предусмотреть наиболее подходящие альтернативы для тех платформ, на которых основной шрифт заведомо отсутствует.
Рекомендуемые альтернативы для шрифтов Windows:
| Основной шрифт | Рекомендуемые резервные гарнитуры |
|---|---|
| Шрифты с засечками (семейство serif) | |
| Georgia | font-family: Georgia, "Times New Roman", Times, serif; |
| Palatino Linotype | font-family: "Palatino Linotype", Palatino, serif; |
| Times New Roman | font-family: "Times New Roman", Times, serif; |
| Шрифты без засечек (семейство sans-serif) | |
| Arial | font-family: Arial, Helvetica, sans-serif; |
| Arial Black | font-family: "Arial Black", Gadget, sans-serif; |
| Impact | font-family: Impact, Charcoal, sans-serif; |
| Lucida Sans Unicode | font-family: "Lucida Sans Unicode", "Lucida Grande", sans-serif; |
| Tahoma | font-family: Tahoma, Geneva, Arial, sans-serif; |
| Trebuchet MS | font-family: "Trebuchet MS", Trebuchet, Helvetica, sans-serif; |
| Verdana | font-family: Verdana, Geneva, Arial, sans-serif; |
| Моноширинные шрифты (семейство monospace) | |
| Courier New | font-family: "Courier New", Courier, monospace; |
| Lucida Console | font-family: "Lucida Console", Monaco, monospace; |
| Курсивные шрифты (семейство cursive) | |
| Comic Sans MS | font-family: "Comic Sans MS", "Comic Sans", Textile, cursive; |
Рекомендуемые альтернативы для шрифтов Mac OS X:
| Основной шрифт | Рекомендуемые резервные гарнитуры |
|---|---|
| Шрифты с засечками (семейство serif) | |
| Georgia | font-family: Georgia, "Times New Roman", Times, serif; |
| Palatino | font-family: Palatino, "Palatino Linotype", serif; |
| Times New Roman | font-family: "Times New Roman", Times, serif; |
| Шрифты без засечек (семейство sans-serif) | |
| Arial | font-family: Arial, Helvetica, sans-serif; |
| Arial Black | font-family: "Arial Black", Gadget, sans-serif; |
| Geneva | font-family: Geneva, Verdana, Arial, sans-serif; |
| Helvetica | font-family: Helvetica, Arial, sans-serif; |
| Impact | font-family: Impact, Charcoal, sans-serif; |
| Lucida Grande | font-family: "Lucida Grande", "Lucida Sans Unicode", sans-serif; |
| Tahoma | font-family: Tahoma, Geneva, Arial, sans-serif; |
| Trebuchet | font-family: Trebuchet, "Trebuchet MS", Helvetica, sans-serif; |
| Verdana | font-family: Verdana, Geneva, Arial, sans-serif; |
| Моноширинные шрифты (семейство monospace) | |
| Courier New | font-family: "Courier New", Courier, monospace; |
| Monaco | font-family: Monaco, "Lucida Console", monospace; |
| Курсивные шрифты (семейство cursive) | |
| Comic Sans | font-family: "Comic Sans", "Comic Sans MS", Textile, cursive; |
Давайте пока укажем для элемента <body>…</body> гарнитуру шрифта Verdana. Впоследствии, в процессе верстки того или иного макета, ничто не помешает нам поменять ее на любую другую.
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
body {font-family: Verdana, Geneva, Arial, sans-serif;}
Как видите, помимо определения основного шрифта, необходимо предусмотреть несколько запасных вариантов, поскольку гарнитуры Verdana на компьютерах некоторых пользователей может попросту не оказаться.
Свойство font-size
О том, что кегль (размер) шрифта задается в CSS при помощи свойства font-size, известно многим. Дебаты обычно начинаются тогда, когда возникает вопрос, в каких единицах измерения его лучше всего задавать.
Вообще каскадные таблицы стилей поддерживают довольно много различных единиц измерения: миллиметры (mm), сантиметры (cm), дюймы (in), пункты (pt), пики (pc), пиксели (px), проценты (%), а также несколько специфические единицы измерения em и ex. Вполне вероятно, что именно сейчас многие из вас, уважаемые читатели, подумают о том, что далее я начну долго и страстно призывать всех задавать размеры шрифтов исключительно и только в процентах и em-ах. Возможно, что года 2 назад я и поступил бы именно таким образом, но только не сегодня. Рискуя прослыть врагом WAI и навлечь на себя гнев ярых приверженцев accessibility, здесь и сейчас я осмелюсь предположить, что все эти проценты и em-ы для определения размеров шрифтов уже неактуальны.
Для непосвященных вкратце поясню: дело в том, что Internet Explorer шестой версии способен масштабировать шрифты на веб-страницах только в том случае, если их размер задан в единицах измерения em или % (единица измерения px в IE6 не масштабируется). Как следствие, на протяжении многих лет наиболее сознательные веб-разработчики вынуждены были соответствующим образом подстраиваться под этот браузер, что порождало целый ряд не совсем очевидных проблем и никому не нужных трудностей. В частности, возникали проблемы несогласованности и округления между относительными единицами измерения. Кроме того, поскольку заданный в % или em размер шрифта всегда рассчитывается относительно размера шрифта родительского элемента, приходилось тщательно высчитывать всякие сложные проценты и дробные em-значения, прибегая время от времени к помощи специального калькулятора.
Так или иначе, по моему скромному мнению заниматься всем этим сегодня уже нет никакого смысла. В конце концов, некоторое время назад все мы имели честь лицезреть очередное чудо человеческой мысли под названием Internet Explorer 8, а проблема масштабирования шрифтов была полностью решена еще в седьмой версии этого браузера. Более того, особенно радует тот факт, что теперь все современные браузеры масштабируют веб-страницы «по-умному» (не только шрифт, но и графические изображения). Причем происходит это с учетом сохранения всех пропорций.
Само собой разумеется, полностью сбрасывать со счетов IE6 пока еще рано. Как бы прискорбно это ни было, поддерживать этот браузер в плане корректного отображения веб-страниц придется еще довольно долгое время, но вот что касается отсутствия в нем возможности масштабирования шрифтов – думаю, что на это можно «закрыть глаза» уже сегодня.
По моему глубокому убеждению при выводе документов на печать наиболее подходящей единицей измерения для указания размеров шрифтов являются пункты (pt), в то время как для точного контроля над экранными шрифтами лучше всего подходят пиксели (px). Давайте зададим для элемента <body>…</body> размер шрифта, равный 11 пикселям. Впоследствии при необходимости мы всегда сможем легко его изменить.
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
body {font-family: Verdana, Geneva, Arial, sans-serif; font-size: 11px;}
Таким образом, заданный для элемента <body>…</body> размер шрифта будет наследоваться большинством структурных элементов документа. Исключение будут составлять только заголовки (h1–h6), а также элементы <big>…</big>, <small>…</small>, <sup>…</sup> и <sub>…</sub>, поскольку для них в таблице стилей по умолчанию размер шрифта определен явным образом. Ну и элементы управления в интерактивных формах по некоторым историческим причинам обычно не хотят наследовать заданные элементу <body>…</body> типографские свойства. В принципе, невелика беда.
Свойство color
Последнее, с чем нам необходимо разобраться в контексте типографских CSS-свойств, – это основной цвет шрифта, который будет наследоваться всеми потомками элемента <body>…</body>. Исключением из этого правила будут являться только поля интерактивных форм, а также те элементы, для которых впоследствии цвет шрифта будет явным образом переопределен.
CSS-свойство color, с помощью которого определяется цвет переднего плана (текста), может принимать множество различных значений. В первую очередь это 17 предопределенных имен цветов: aqua (аквамарин), black (черный), blue (синий), fuchsia (фуксия), gray (серый), green (зеленый), lime (светло-зеленый), maroon (бордовый), navy (темно-синий), olive (оливковый), orange (оранжевый), purple (пурпурный), red (красный), silver (серебристый), teal (бирюзовый), white (белый) и yellow (желтый).
На практике применение ключевых слов для определения цвета может выглядеть примерно следующим образом:
body {color: black;} /* Черный цвет */
body {color: green;} /* Зеленый цвет */
body {color: white;} /* Белый цвет */
Другим способом определения цвета является использование числовых или процентных значений для указания отдельных составляющих цветовой модели RGB:
body {color: rgb(0, 0, 0);} /* Черный цвет */
body {color: rgb(0, 128, 0);} /* Зеленый цвет */
body {color: rgb(100%, 100%, 100%);} /* Белый цвет */
Еще одним альтернативным методом определения цветов в CSS является использование шестнадцатеричных значений, которые всегда предваряются символом «#». Каждая последующая пара символов (после символа «#») соответствует одной компоненте RGB в шестнадцатеричной системе счисления:
body {color: #000000;} /* Черный цвет */
body {color: #008000;} /* Зеленый цвет */
body {color: #FFFFFF;} /* Белый цвет */
На каком же из перечисленных выше методов лучше остановиться? По правде говоря, это не более чем дело вкуса. Лично я, например, предпочитаю шестнадцатеричные значения:
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
body {font-family: Verdana, Geneva, Arial, sans-serif; font-size: 11px; color:#000000;}
Пусть пока цвет текста для элемента <body>…</body> будет черным. Впоследствии мы сможем легко поменять его на любой другой.
Изображения в рамках
Ни для кого не секрет, что некоторые браузеры (Internet Explorer, Firefox) до сих пор продолжают обрамлять изображения-ссылки в документах никому не нужными границами-рамками (borders). В чем заключается тайный смысл подобного поведения браузеров доподлинно неизвестно. Вполне возможно, что это как-то связано с вопросами доступности контента (accessibility), но более-менее внятного объяснения этому феномену лично мне в свое время найти так нигде и не удалось. Буду признателен, если кто-нибудь поделится ссылкой на соответствующий тематический материал.
Так или иначе, в старые, но опять-таки совсем не добрые времена, отключение рамок у изображений-ссылок осуществлялось, как правило, следующим образом:
<img src="image.jpg" alt="" border="0">
В одной из предыдущих публикаций я уже как-то отмечал, что поступать подобным образом ни в коем случае не следует. Гораздо логичнее и правильнее решить поставленную задачу с помощью каскадных таблиц стилей. Именно это нам сейчас и предстоит сделать.
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
body {font-family: Verdana, Geneva, Arial, sans-serif; font-size: 11px; color:#000000;}
img {border: none;}
Таким образом, благодаря всего лишь одному стилевому правилу, мы навсегда избавляемся от рамок вокруг всех изображений-ссылок в HTML-документе.
Связываем CSS-файл с HTML-документом
Для того, чтобы таблица стилей смогла повлиять на представление документа, пользовательские агенты должны знать о ее существовании. На сегодняшний день наиболее оптимальным способом решения этой задачи является использование элемента <link>. Давайте добавим в наш базовый HTML-документ соответствующую инструкцию:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Базовый документ для практических занятий по верстке</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="css/main.css" rel="stylesheet" type="text/css" media="screen, projection">
</head>
<body>
<div></div>
</body>
</html>
Элемент <link> является «пустым» и может находиться только в пределах элемента <head>…</head>. Хотя данный элемент и не имеет содержимого, он выражает информацию о взаимоотношениях различных документов и файлов с помощью нескольких важных атрибутов: href, rel, type и media.
Атрибут href предназначается для определения адреса связываемого объекта. Поскольку наш базовый стилевой файл располагается в отдельной папке, значением данного атрибута должен быть соответствующий путь и имя CSS-файла (css/main.css). Два других атрибута элемента <link> определяют тип взаимосвязи текущего документа с объектом и тип содержимого связываемого объекта. В данном конкретном случае значение атрибута rel должно обозначать внешнюю таблицу стилей (stylesheet), а в качестве значения атрибута type должен быть указан стандартный для таблиц стилей тип MIME (text/css).
Как уже было отмечено ранее, одним из важнейших достоинств каскадных таблиц стилей является возможность задавать отдельные стилевые правила для разных устройств вывода (обычные мониторы, портативные устройства, принтеры, речевые синтезаторы и т.п.). Как правило, для разных устройств представления создаются отдельные стилевые файлы, которые подключаются к HTML-документам описанным выше способом, а с помощью атрибута media указываются конкретные типы устройств, для которых предназначается тот или иной CSS-файл.
Поскольку в данный момент мы создаем стилевой файл, определяющий порядок отображения HTML-документа обычными визуальными браузерами, значением атрибута media должен являться тип устройств screen (экран монитора). Кроме того, в качестве целевого устройства также можно указать и цифровой проектор (projection), поскольку, во-первых, для данного устройства, как правило, не требуются какие-то особые стили отображения (существенно отличающиеся от стилевых спецификаций для обычных мониторов), а во-вторых, в случае наличия таких специфических стилей отображения (для типа устройств projection) браузер Opera при полноэкранном просмотре документов (клавиша F11) почему-то полностью игнорирует стилевые спецификации, определенные для типа устройств screen.
В принципе, атрибут media может принимать значение all, что равнозначно отсутствию этого атрибута у элемента <link>. В этом случае все стилевые правила в подключаемом CSS-файле будут относиться к любым устройствам вывода. Само собой разумеется, подобный бардак нам совсем ни к чему. Если мы изначально надлежащим образом разграничим стилевые инструкции, в дальнейшем нам ничто не помешает создать еще один стилевой файл, предназначенный для вывода нашего документа на печать или определяющий правила отображения документа на экранах мобильных телефонов.
Заключение
Давайте кратко проанализируем проделанную работу. Мы создали базовый стилевой файл main.css, поместили его в отдельную папку, воспользовались универсальным селектором для обнуления полей и отступов у всех структурных элементов, задали фоновый цвет элементу <html>…</html>, назначили гарнитуру, размер и цвет шрифта для элемента <body>…</body> и отключили границу (рамку) у элементов <img>. Затем мы связали наш базовый HTML-документ с полученным CSS-файлом при помощи элемента <link>.
Файл main.css:
@charset "utf-8";
* {margin: 0px; padding: 0px;}
html {background: #FFFFFF;}
body {font-family: Verdana, Geneva, Arial, sans-serif; font-size: 11px; color:#000000;}
img {border: none;}
Напоследок мне хотелось бы отметить, что предложенные выше базовые стилевые правила не являются идеальными или единственно правильными. Безусловно, у каждого из нас есть свои собственные предпочтения, и я совсем не хочу, чтобы вы всегда и во всем разделяли мою точку зрения. К примеру, вполне возможно, что вам будет удобнее задавать гарнитуру и размер шрифта посредством одного стенографического (обобщающего) свойства font вместо определения этих характеристик по отдельности (с помощью свойств font-family и font-size). Тем не менее, все желающие могут скачать архив с готовым базовым документом и соответствующим стилевым файлом. Именно эти шаблоны мы будем использовать во всех последующих практических занятиях.
Ссылка на комментарий 09.07.2009 23:01
Павел Азовский
Украина
http://azovsky.com.ua
Спасибо за подробную статью! Хоть это и самые основы, но зато очень важные!
На счет em или px для указания размера шрифтов - согласен! Сейчас актуальней становится все-таки второе.
Ссылка на комментарий 21.07.2009 17:43
Kolridg
Россия
http://htmlmaster.ru
По поводу использования px вместо относительных единиц, таких как em, % и др.
Если, например, пользователь преднамерено увеличил базовый размер шрифтов у себя в ОС или браузере чтобы не масштабировать каждую страницу отдельно, будет ли влиять эта корректировка на шрифты заданные в px?
Если нет, то это хорошо, потому что был случай когда в заведомо «нерезиновом» графическом элементе текст не помещался и складывлся гармошкой, потому что пользователя был увеличен базовый размер шрифта в ОС.
То есть, можно было бы выбирать, где давать возможность увеличивать текст заранее, а где только при увеличении всего масштаба страницы, при котором пропорционально увеличиваются и графические элементы. Чтобы избежать подобных ситуаций, что я описал выше.
Самостоятельно проверить это не удалось, в силу того, что у себя в XP 2000 не нашел, где можно увеличить базовые размеры шрифта. Прошу помочь с этим экспериментом, если он имеет смысл.
Конечно, при увеличении масштаба страницы, уже и без того увеличенный по умолчанию базовый размер шрифта увеличиться еще на порядок. Но по крайней мере это лучше чем, не помещающийся корявый текст в определенных частях страницы.
И конечно же, если корректировка базового размера шрифта в ОС не влияет на размеры заданные в px, то отказываться от относительных единиц нельзя. Потому что, если пользователь хочет постоянно иметь несколько крупный размер шрифта, чем обычный, то вполне разумно предополжить, что он увеличит его один раз в ОС, но не будет масштабировать каждую страницу в отдельности.
Собственно, из-за этого я и поднял вопрос, а применение px для деликатных ситуаций, это уже скорее развитие темы.
Ссылка на комментарий 21.07.2009 20:41
Константин Ефимов
Россия, Тольятти
http://webstandards.org.ru
Если размер шрифтов в ОС увеличен на вкладке «Оформление» свойств экрана, то это никак не отразится на содержимом веб-страниц. При этом совершенно не имеет никакого значения, в каких единицах измерения задан на веб-страницах размер шрифтов. Если же речь идет об изменении размеров шрифтов в браузерах, пиксели не будут масштабироваться только в IE6 (об этом подробно рассказывается чуть выше).
Другое дело, если размер шрифтов в ОС увеличивается не на вкладке «Оформление» свойств экрана, а вот здесь: свойства экрана -> вкладка «Параметры» -> дополнительно -> масштаб (количество точек на дюйм). Здесь уже речь идет об увеличении общего масштабного коэффициента, а не только о размере экранных шрифтов. Именно в этом случае в некоторых браузерах (IE6, IE7 и Opera) может возникать что-то наподобие «текст не помещался и складывался гармошкой», но только при указании размера шрифтов в em-ах. Это можно вылечить, но на сегодняшний день гораздо проще и логичнее задавать размеры экранных шрифтов в пикселях. Это позволяет более точно контролировать их размеры и обходиться без каких-либо «лекарств».
Ссылка на комментарий 25.07.2009 16:34
Kolridg
Россия
http://htmlmaster.ru
Спасибо. Ситуация прояснилась.
В таком случае sliding doors также становятся неактуальными?
Призыв использования px вместо em также встречал в публикации одного зарубежного дизайнера. Основная суть его идеи в том, что дело не только в том что IE6 уже достаточно устарел, но и качественный дизайн предпологает размеры шрифтов один один с размером в макете, что при относительных размерах добиться практически невозможно или крайне тяжело. Этот момент, кстати, у Вас в статье освещен в должной мере.
Итого, мы не одиноки во вселенной)
Ссылка на комментарий 25.07.2009 16:56
Константин Ефимов
Россия, Тольятти
http://webstandards.org.ru
Sliding Doors выручают не только при масштабировании шрифтов в старых браузерах, но также и в тех ситуациях, когда имеет место увеличение длины строки текста посредством CMS.
Ссылка на комментарий 01.08.2009 02:19
Виталий
Украина, Херсон
Спасибо за статью, для начинающих но все же познавательно.
Ссылка на комментарий 05.08.2009 18:21
LeonMax
Украина, Харьков
Скажите, стоит ли использовать сокращенную запись цвета, например #fff вместо #ffffff ?
Ссылка на комментарий 05.08.2009 20:15
Константин Ефимов
Россия, Тольятти
http://webstandards.org.ru
Это вопрос личных предпочтений каждого веб-разработчика. Если Вам так больше нравится, используйте на здоровье. Никакой принципиальной разницы между полным и сокращенным вариантами записи не существует. Другое дело, что далеко не каждое значение можно сократить.
Ссылка на комментарий 06.09.2009 16:13
bum
Молдова, Тирасполь
Большое спасибо за статью.
А что, если «неглавные» html-файлы также должны лежать в отдельной папке. Как в этом случае ссылаться этим файлам на main.css, который также лежит в поддиректории?
Ссылка на комментарий 06.09.2009 18:36
Константин Ефимов
Россия, Тольятти
http://webstandards.org.ru
Указывать путь от корня веб-сайта:
<link href="/css/main.css"...Ссылка на комментарий 19.10.2009 19:27
DELPHIna
Россия, Великий Новгород
Вот ты предлагаешь обнулять свойства так:
* {margin: 0px; padding: 0px;}img {border: none;}
а я на некоторых сайтах видела такой способ:
* {margin: 0px; padding: 0px;border: none;}
чем он плох?
а за статью спасибо :) побольше бы писал!!!!
Ссылка на комментарий 19.10.2009 19:41
Константин Ефимов
Россия, Тольятти
http://webstandards.org.ru
Плох он тем, что в данном конкретном случае будут отключены границы у всех элементов в документе. То есть совсем у всех, включая элементы управления (input, textarea и т.п.), что далеко не всегда удобно и приемлемо.
Ссылка на комментарий 15.02.2010 19:08
Антон
Россия
http://htmlmaster.ru
Я бы раскрыл ответ так: в силу того, что картинки по замыслу дизайнера не всегда имеют бордюры, в то время как поля ввода и текстовые зоны имеют их всегда, поэтому ни к чему отключать то, что все равно будет использоваться.
И эти все элементы можно наглядно видеть в браузере
еще на этапе структуры. Иначе говоря, если вы еще не стилизовали форму, но уже просмотрели результат в браузере.
Если же бордюры будут отклюены, полноценная наглядность
исключена: будут видны только элементы управления: «стрелочки выпадушек» и скроллы(промотка).