alexpop

О! так тут всего один шаг до "почти" нормальной верстки! Типа так: http://jsfiddle.net/alexpop/6adLm/5/ Хотя не идеально, доли процентов скачут койгде

Вопрос конечно открытый и опциональный. Но вот, например начало CSS :focus {outline:0;} .clear {clear:both; visibility:hidden; height:0;} .clearfix {zoom:1;} .clearfix:after {content:"."; display:block; height:0; clear:both; visibility:hidden;} /* DOC general ———————————-*/ html {height:100%;} body {font:81.2%/140% Arial, sans-serif; background:#F8F8F8; margin:0; height:100%; color:#444;} a:link, a:visited {text-decoration:none; color:#333;} a:hover {text-decoration:underline; color:#000;} a:active {text-decoration:none; color:#555;} h1,h2,h3,h4,h5,h6 {font-family:'Segoe UI', Arial, sans-serif;} h1 {font-size:1em; margin:0;color:#777;} h2 {font-size:25px; font-weight:normal; line-height:110%; margin:1em 0 .5em; color:#000;} h3 {font-size:19px; line-height:120%; margin:1em 0 .5em; color:#000;} h4 {font-size:16px; margin:1em 0 .5em;} h5, h6 {font-size:1em; margin:.5em 0;} p {margin:0 0 .75em 0;} ol {margin:.25em 0 .75em; padding:0 0 0 3em;} ul {margin:0; padding:0; list-style:none;} dl {margin:.25em 0 .75em;} dt {font-weight:bold; } dd {margin-left:1.5em;} table {border-collapse:collapse; border-spacing:0; text-align:left;} img {border:none;} /* Forms */ label { font-weight:bold; } fieldset { padding:0 1.4em 1.4em 1.4em; margin:0 0 1.5em 0; border:1px solid #eee; } legend { font-weight:bold; font-size:1.2em; margin-top:-0.2em; margin-bottom:1em; } fieldset { padding-top:1.4em; } legend { margin-top:0; margin-bottom:0;} /* Custom Typo ———————————-*/ img.left {float:left} img.right {float:right} .topzero {margin-top:0;}/* to reset headers top margin */ .title { display:block; font-size:107.69%; font-weight:bold; text-transform:uppercase; } /* .txt suffix for typography content in a text blocks */ .txt ul li { background:url("img/bg-ul-1.png") no-repeat scroll 0 4px transparent; padding:0 0 0 1.5em; margin:0 0 0 1.5em; } .txt ul li li { background-image:url("img/bg-ul-2.png"); } .txt img { margin:5px 20px 7px 0; } /* Table, add .txttab class to table */ .txttab { border-top:2px solid #666; border-bottom:1px solid #ccc; line-height:120%; width:100%; margin-bottom:20px; } .txttab caption { font-weight:bold; text-transform:uppercase; padding:0.4em 5px; } .txttab th, .txttab td { border-top:1px dotted #ccc; padding:0.4em 5px 0.6em; vertical-align:top; } /* tags */ /* tags shadow and radius */ .bg-green a, .bg-blue a { display:block; font-size:92.33%; line-height:1.4em; margin-bottom:1px; padding:0 8px 1px; -moz-border-radius:2px; -webkit-border-radius:2px; border-radius:2px; -moz-box-shadow:1px 1px 1px rgba(0, 0, 0, 0.15); -webkit-box-shadow:1px 1px 1px rgba(0, 0, 0, 0.15); box-shadow:1px 1px 1px rgba(0, 0, 0, 0.15); font-size:92.33%; } .bg-yellow a, a.bg-yellow { background-color:#F2E486; } .bg-green a, a.bg-green { background-color:#E8FFE8; } .bg-blue a, a.bg-blue { background-color:#DDF1FA; } .bg-yellow a:hover, .bg-green a:hover, .bg-blue a:hover, a.bg-yellow:hover, a.bg-green:hover, a.bg-blue:hover { background-color:#555; color:#EEE; text-decoration:none; } 1. Например, в заголовках я явно прописываю свойства для каждого, хотя мог бы группировать. В остальных элементах - чаще наоборт. 2. Стараюсь сохранить баланс (не знаю насколько успешно) в наследовании классов. Хотя именно в этом макете я прописывал многие свойства для каждого объекта, но меня подмывает разложить их в разные группы. 3. ID использую только как хуки для скриптов. Кроме того, я разрываюсь между концепцией хранить разные свойства в разных группах, и присваивать их к разным обектам и явным прописанием свойств для каждого элемента. В первом случае конечный объект хватает параметры из нескольких описаний, которые суммируются. Плюс тот, что изменяя всего в одном месте значение - я изменяю весь сайт махом. Минус - несколько обращений на элемент. Не знаю, насколько это принято. Как-то так... Например. DIV получает цвет фона из одного набора, цвет шрифта из другого, тени из третьего, закругления из четвертого

3. Если на картинку мышь навести то выскакивает прозрачный слой и "опадает" 200 мсек. Во всех броузерах это проискодит плавно, а в файрфоксе скачками. Jquery 5. Это я про конструкцию HTML-CSS Дело в том, что я раньше ни с кем не советовался, делал все так как считал "правильным", поэтому не знаю, насколько чистый код и т.п.

Активно изучаю веб, и пробую новые приемы в CSS3 и.т.п. Делаю себе новую шкуру с использованием некоторых прибамбасов. http://dgbomb.com/maket/ Есть несколько вопросов: 1. Насколько сильно эффекты закруглений, CSS транзишн, тени и т.п. грузят броузер. Может, все это лучше картинками сделать? 2. У меня макет пересчитывается через CSS на несколько разрешений. То есть, на разнах разрешениях - разная ширина макета. Насколько это приемлимо. Или лучше сделать через скрипт. 3. Заметил, что слайдеры на превьюшках в файрфоксе анимируются скачками. Это особенность броузера? Или у меня косяк. 4. Общий вопрос. Как сохранить баланс в наследовании классов типа .style ul li ul {} или .sub-style-ul ul {} или .sub-style-ul-ul {}. Насколько в реальности грузит броузер подобное наследование? 5. Ну и по возможности насколько грамотная сборка...

Действительно, если верить спецификации, то для картинок figure - самое оно. Но вместе с этим, в спецификации указывается более широкий функционал: Что я бы перевел так: Элемент figure представляет собой некий поточный контент, (опционально с подписью), который является самодостаточным и обычно рассматривается как отдельный объект в основном потоке документа. Таким образом – Элемент может быть использован как аннотация к иллюстрации, диаграммам, фотографиям, листинг кода, и т.п. Этот элемент является дополнительным к основному контенту, но при этом может (без изменения структуры документа) вынесен от первичного контента. Например, в сайдбар, спец.страницы, или приложения. Я предположил, что тут картинка (типа лого сайта или иллюстрация), которая чаще всего тут и находится, плюс некоторый дискрипшн сайта в целом. Но делать на ней смысловой акцент - как-то нецелесообразно. Поэтому я и запихал всё это дело в фигуру. Именно по этой причине - если бы я изловчился, и вместо дивов использовал теги разметки, то как бы я поменял потом семантику, если бы это нужно было? Вот, например – сайт, ну скажем, новостной портал, или просто блог имеет 2-3 макета страниц. А контент в этих макетах очень разный, и акценты так-то разные могут быть. Если бы весь макет "висел" на тегах семантики, то тогда все бы страницы были семантически одинаковы. Как только ты привязал семантику к каркасу - сразу "убил" возможность пользоваться разметкой по своему усмотрению на разных страницах имхо. Что мы делам в этом случае? Оставляем те-же 2-3 каркаса, и делаем Семантические модификации, например. Или вот с чем еще можно сравнить: Как CSS отделяет "визуал" от "Содержимого" сайта, так и Семантические теги позволяют отделить "Смысл" от "Визуала" (не факт, что нужно, но бывает. Под визуалом я понимаю не "яркую и веселую картинку" сайта, а каркас (CSS + HTML). Иногда позволяют свести "Содержимое" и "Смысл". Вместе. Еще раз подчеркну - я специально "разломал" макет, чтобы проверить возможности. И когда я сделал дублирующую страницу на заголовках, ровно с тем-же дизайном, но с совершенно иной семантикой - у меня ушло на это 2 минуты. Убил контейнеры семантической разметки и поменял h1 на h2 и h3 кое-где. И все. А если бы констукция висела на этих тегах? А? И, кстати, именно по этой причине я не использую ID в CSS макета. Все на классах строится. Недавно разрабатывал интерфейс админки, полностью напичканому ID автоматизацией, которая во-первых динимическая, и к тому-же - мне неизвестная.

Спасибо! Мой косяк. Я поправил там текст на следующий: На самом деле, это вопрос возник у меня от собственной невнимательности. Влад Мержевич на форуме forum.htmlbook.ru открыл мне глаза. Дело в том, что многие разработчики в CSS явным образом прописывают display:block;. Из чего я сделал поспешный вывод, что это инлайн-контейнер. Не удосужившись проверить это, я решил, что так оно и есть. Тем не менее, элементы article, aside, details, figcaption, figure, footer, header, hgroup, menu, nav, section (возможно, еще какие-то) рендерятся современными броузерами как блочные контейнеры. Но! IE до 9 версии действительно трактуют как строчный контейнер. Это и стало причиной моего заблуждения.

Да, согласен. Разные броузеры трактуют по-разному. Я так назвал для условности. Я обратил на это внимание, но не смог подобрать определение из известных. Могу поправить, только не знаю, на что... ))

Признаюсь, я не смог найти в интернете ничего "железного" насчет разметки, поэтому и решил читать оригинал. Вот, что буквально написано про спецификация nav: The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Элемент nav отображает раздел страницы, который линкуется с другими страницами или частями самой страницы: раздел с навигационными линками. (В общем это и так понятно) А далее иду комментарии: Не все группы сcылок на странице нуждаются в элементе NAV, элемент изначально предполагался для разделов, что содержат навигационные блоки. В частности в футере содержится много ссылок на внутренние страницы сайта, типа правила пользовани, домашняя, страница копирайта и т.п. В основном footer справляется с этой задачей, тогда как nav хотя и может быть использован в подобном случае, но в этом нет необходимости. Суть второго замечания следующая: Если просмотровые устройства позволяют получать доступ к навигационной информации, не отображенной ранее, либо которые могут мгновенно показывать навигационные запросы - могут использовать этот элемент для выбора пропускать ли эту часть или показывать сначала. (Если честно, не представляю о чем речь... темнота) Следующие три примера кода иллюстрируют случаи, когда используется 1 nav тег, при том, что есть два блока с ссылками, но лишь однин блог - навигационный. Второй пример использует ДВА ТЕГА nav (!) один блок ссылок на другие страницы сайта, а второй на блок ссылок на самой странице. И третий пример, который вообще не является списком, а просто какой-то текст с контекстыми ссылками. Никаких ограничений нет на первый взгляд. Но могу предположить, что это поверие идет от того, что мол краулеры запутаются в поиске? Не думаю. Сейчас то все нормально, а это всего-лишь подсказка. А откуда такая тема?

Всем привет, пытаясь понять теги семантической разметки HTML5 я сделал макет-статью, в которой попытался субъективно проанализировать спецификацию W3C. Мне интересно ваше мнение насчет моей трактовки. И как вы понимаете этот вопрос. Демо-страница находится здесь Целиком текст на форум не влазит, вот фрагмент: В этом макете-статье я пытаюсь разобраться с применением новых тегов разметки в HTML5. Все это исключительно мои субъективные выводы. Принимать ли вам на веру это, или перепрверить – решайте сами... Здесь я не буду рассказывать о новом функционале, сосредоточусь только на тегах семантических элементов типа: article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section...