Kray Storm

По идее нужно <article> задать overflow:hidden, например. Тогда он начнет учитывать float-ы. Ошибка в неполном понимании особенностей плавающих элементов. Как говорится, почувствуй разницу: 1. http://jsfiddle.net/jYuVJ/ 2. http://jsfiddle.net/jYuVJ/1/ 3. http://jsfiddle.net/jYuVJ/2/

Потому что везде три строки текста, а в последнем блоке - две. Потому что все там держится на нижних отступах. И потому что блочные элементы игнорируют плавающие (!).

Как вариант: http://jsfiddle.net/Dvp22/1/ Ну и сразу, чтобы со смежными border не возиться: http://jsfiddle.net/Dvp22/2/

Зато там есть комментарии, в которых есть решения. И их там около десятка. В чем проблема?

Есть еще :nth-of-type. А если там внутренних <div> так и будет всего два, то можно и через соседний селектор. А чем :first-child не угодил?

Практика: Тот зазор в 1px сверху - это реакция float-элемента на вложенные inline. Делаем их inline-block и зазор пропадает. http://jsfiddle.net/WuxvJ/1/ Теория: Это все круто, но кто обьяснит - почему так происходит? ))

<ul> дать font-size:0;, и потом "вернуть" нужный размер <li> UPD: А, тут не тот случай. Извиняюсь - тупанул.

Курс веб-графики в вузе? Круто (хоть и на фреймах). А это на каких специальностях сейчас такое проходят, если не секрет?

Люди! Ну напишите хотя бы что я дурак и вопрос глупый. Или что в браузерах это нормально и так всегда было и все были довольны. Я хоть тогда буду спокоен. Спасибо ))

Здравствуйте. Есть простой код с формой, состоящей из строки поиска и кнопки. Есть желание задать оформление: placeholder + скругление + тень при фокусе. Казалось бы - куда уж проще. Но браузеры дружно доказывают, что я слишком наивен в своих предположениях. Вот код Тот же jsfiddle все отображает как задумано: тыцяем в поле - текст пропадает, граница и тень появляются. Opera: аналогично. Firefox 19.0.2: текст из placeholder пропадает не при фокусе, а только после начала набора текста запроса. Chrome 25 удивил: бордера, тени и скруглений нет, реакции на фокус тоже нет. Гугл толком ничего не сказал - только по placeholder-у нашлось решение на Javascript. Вопрос: Возможно ли сделать кроссбраузерную строку поиска без использования скриптов?

Можно при помощи таблицы: Элемент <ul> сделать display:table; с width:100%; и обязательно table-layout:fixed;. Пунктам <li> задать display:table-cell; и выровнять содержимое по центру. Контент внутри <li> можно поместить в блок (с display:block;) для удобства. Родителю <ul> задать ширину и выравнивание. Получим таблицу, растянутую по всей ширине, с автоматическим делением на равные по ширине колонки.

На счет семантики, потери сути html/css и усложнении - это да. Потому и спросил, что способ вроде такой есть, а что с ним делать - непонятно.

Здравствуйте. Решил после теории попробовать силы и помучить "Практикум" на сайте. Задание 3 "Вложенные списки". Понятно, что решение просто и очевидно. Но тут внезапно(!) возник синдром "Мы не ищем легких путей" и тяга к "Великой оптимизации". Идея в том, что в html мы не вписываем вручную однотипные наименования пунктов и однотипную нумерацию. А просто используем :before и after. Что как бы более соответствует прекрасной идее - "HTML создается только раз и дальше все редактируем только через CSS". Собственно, код. Внешне все выглядит также, как на html-списках и валидно. Вопрос: 1. Есть ли какие-то подводные камни в таком подходе - почему он может быть плох? Старые IE не считаем. 2. И... где такое можно/нужно использовать в реальности?

margin-left для выравнивания по центру? А что мешает вон тому <p>, который <p> <span style="font-size:48px;"> <span style="font-family: courier new,courier,monospace;">бла-бла-бла</span> </span> </p> задать в стилях например: margin:auto; А внешнему контейнеру сверху - небольшой отступ в %. Будет и по центру, и сверху отступ на разных экранах - пропорциональным.

Чтоб не было косо нужно "Найти и уничтожить" вот это: .odkl-klass-s, .odkl-klass { display: inline-block; overflow: hidden; text-indent: -3000px; vertical-align: middle; }

Только вот браузер об этих правилах не знает )) Как ему рассчитать равные отступы от краев блока до контейнера, если не задана сама ширина блока? #topmenu ul { padding: 0; margin: auto; width: 417px; /*Теперь все по центру*/ list-style: none; font-family: "Trebuchet MS"; font-size: 21px; text-decoration: none; color: #fff; }

Да уж. Очень странно, если учесть, что у самого футера зачем-то отрицательный margin со стороны контента и нет выравнивания по горизонтали А fixed зачем? Ведь нужен прижатый футер при малом количестве контента, который едет вниз, когда контента прибыло, а не фикс-бар внизу экрана? В общем, html похоже, а css какое-то слишком "универсальное". Есть вот такой способ. Содержимое должно находиться внутри <div id="content">. И никаких clear:both футеру не нужно. Если есть плавающие блоки, то они будут удерживаться в #content за счет overflow. Естественно, всю схему можно еще обернуть, чтобы было удобно задавать min-/max-width и центрирование. Насчет Opera Fix не знаю, но для старых IE "фиксы" нужны (там у них всякий hasLayout и все такое...). В условный коммент для IE нужно добавить: #main{height:100%;}

1. А все ли браузеры одинаково понимают значения border:medium и outline:medium? Или лучше задать их в px? (Мысли вслух). 2. В <div class="step3 step"> кнопка "read more" из-за текста уехала вниз. 3. В форме Request a Quote какие-то placeholder-ы странные. Они же при нажатии должны пропадать. 4. Для чего в css-файле для .header писать значения {background: none repeat scroll 0 0 #FFFFFF;} когда там нет изображения? И таких "лишних" значений много. Или это ВИЗИВИГ на страже порядка? 5. Использование блока <div class="header_content wrap_content"> кажется лишним. Высоту и position для отсчета <a class="ribbonFAQ"> можно задать в том же <div class="header">. Хотя и не мешает, с другой стороны. 6. Что меняет наличие в .top_content {z-index: 2;}? 7. Возможно, это дело вкуса, но вместо того, чтобы задавать position для <div class="promo"> и <div class="motto"> + смещения, можно было просто в .motto указать {margin: 260px 0 0 30px;}.

А что тогда насчет outline? Он-то в формировании габаритов не участвует, в отличие от border. Или box-shadow?

А вот теперь мне подскажите. Где там треугольник и зигзаг? Вроде по repeat-x там обычный прямоугольный фрагмент, который спозиционирован по background-position. Если нужен плавный переход на стыке - фрагмент с градиентом шириной в 1px. Нет?

Подсветка территории для высадки космодесанта? Интерактивная карта по-научному. Вот тут как раз такое.

Вот тут Firefox уже не согласен и теперь с радостью отобразил #left на всю высоту #main (которая как раз min-height:70% от <body>), т.е. подход сработал. Опера, умница, изначально над этим не заморачивалась. А вот Хром, зараза, как и положено самому прогрессивному браузеру, лишь презрительно хмыкнул и назло посчитал от 1%, да (вот в нем я и не проверил). Продолжая тему - что можно сделать с Хромом? Есть способ или лучше сразу признать подобную модель негодной? PS: Откуда вообще такой разлет в таком банальном вопросе - от чего считать % для min-height?

Офигеть. Это ж надо - какой абсурд. Выходит, что если думать "как роботы", то min-height - это лишь ограничитель высоты блока. А height - значение этой высоты. И для рассчета min-height для #left в %, нужно чтобы у #main было именно значение. Торжественно добавим же его! #main{ overflow:hidden; width:50%; height:1%; min-height:70%; margin:auto; background:#ccf; Теперь робот говорит "ОК. Наконец-то у нас для #main есть величина height:1%, которую мы все-равно не используем, потому как у нас есть ограничитель min-height:70%; Поэтому теперь(!) мы наконец можем отсчитать min-height:100% для #left, который возьмем от величины рассчитаной как min-height:70% для #main". И на тот факт, что это будет та же величина, которую браузер точно также рассчитал от того же <body> в первый раз и без всякого height:1%, роботам плевать. Ну да! Там же не была указана высота! WTF?! SelenIT спасибо за пояснение. Теперь понятна вся суть слов "If the height of the containing block is not specified explicitly...". Логику отключаем. )

Проблема, она в... рисунке и в... таблице. Простите мою дерзость, уважаемый профессор , но у подобных "эскизов", бывают размеры по горизонтали и по вертикали. И при принятии этого допущения, правая колонка вводит в глубокие размышления (хотя, наверное, я слишком много думаю). А вот размеров px в html не бывает. Также как и height="100%", если у контейнера для таблицы (<body>) и у контейнера этого контейнера (<html>) не задана высота явно в % от области просмотра. Однако, хорошая новость состоит в том, что пока у нас есть листики в клеточку - эту страну не победить! )))

Как там всего много... 1. Это не столько <div id="picframe"> перекрывает div id="tovar">, сколько изначально <div id="contentFlow"> "не пускает" <div id="tovar"> на область <div id="picframe"> из-за скрытия переполнения. .ContentFlow { overflow: hidden; 2. У <div class="flow">, который родитель для <div id="tovar"> .ContentFlow .flow { z-index: 0; а у <div id="picframe"> #picframe { z-index: 1; наверное поэтому #tovar { z-index: 2147483647; у блока <div id="tovar"> не сильно ему помогает.