SelenIT

В файрбаге. Но в принципе это и по приведенному в стартовом посте коде видно...

В div обернуты все пункты. Но первый пункт - голый текст, остальные обернуты в <p>. А для p прописан font-size: 1.1 em, т.е. увеличение шрифта на 10% по сравнению с указанным для предка (div-а в данном случае), т.е. 8.8px, округляется до 9. Если абзацы генерятся автоматически, лучше относительного размера шрифта на них не вешать. Смысл бледного комментария был в том, что абзацы не могут содержать блочных элементов и неявно закрываются перед любым из них (т.е. запись <p><div> полностью эквивалентна <p></p><div>).

Только во всех вышедших IE он не двухцветный, а так нормально. Как вариант, для IE можно приложить картинку через AlphaImageLoader...

Не делайте пустой абзац ради отступа, лучше ставьте margin для div. Надеюсь, вы не рассчитываете, что в результате такой конструкции div у вас окажется внутри абзаца? )

В классе (в квадратных скобках то бишь) не может. Так что надо что-то вроде [a-zA-Z0-9]+([a-zA-Z0-9_.-]+[a-zA-Z0-9_-])?@... Меня, честно говоря, в таких регулярках сильнее напрягает [a-z]{2,4} (с учетом существования .museum и .travel). Правда, в данном случае написана вообще фигня (.[a-z]{2,4} вместо \.[a-z]{2,4}, т.е. совпадение с любым символом, а не точкой как таковой!), так что .museum пройдет, как и .abracadabra . Вообще не вижу большого смысла в таких проверках — если юзер заинтересован (напр., должен получить письмо для подтверждения регистрации), ему так и так придется ввести реальный e-mail, а если хочет ввести фигню для отмазки, самая дотошная валидация не помешает ему ввести какой-нибудь "123@aaa.com". Имхо, валидация e-mail на клиенте нужна только, чтобы подстраховать юзера от глупой опечатки, и для этого достаточно базовой проверки на "собаку" и точку. Или упрощенного аналога поведения <input type="email"> в HTML5...

Забудьте уже про -webkit-border-radius. Браузеры, не понимающие беспрефиксного синтаксиса, вымерли больше года назад и не стоят упоминания в приличном обществе

А что, нормальный такой код для троллинга спискофагов . Хотя я согласен с Gaspode — если возникла такая мысль, то нужно смело писать <div>Пункт | Пункт | Пункт</div> и не париться). Это очевидный показатель, что список там не нужен.

Кстати, по новой спеке градиентов, привязка к углу (нововведенное "to") должна давать искомое поведение (example 18 — как раз что надо, с точностью до цветов и ориентации). Дело, как обычно, за малым — поддержкой браузеров... Почему "конечно же"? А без префиксов, для актуальных версий — разве нет?

В каменном веке для этой цели для ul ставили overflow:hidden и смещали крайний пункт за его границу (margin-left: -1px для первого или ...-right: -1px для последнего, по ситуации). Сейчас вполне можно юзать любой из способов, предложенных выше. Если разделитель цепляется через псевдоэлемент, то :first-child уж точно работать будет (а если для IE8 допустима деградация, то можно и к :last-child обратиться).

Можно саму обертку скруглить.

Мда, свинство у линейных градиентов, что они не меняют угла при смене пропорций в background-size (главное, радиальные прекрасно сплющиваются и растягиваются, а тут...). С трансформами смог добиться только того, чтобы правый верхний угол был на месте (для квадратных картинок, как в стартовом посте, получается нужная пропорция, для остальных — хотя бы более-менее терпимо). Похоже, самое простое и действенное решение — в самом деле наложить этот уголок обычной png-картинкой размерами 100% на 50% враппера...

Как вариант.

Многие и так по сей день верстают таблицами и чураются блочной верстки . И так будет, пока все браузеры не начнут поддерживать хотя бы один CSS-механизм, заточенный именно для раскладки блоков (сейчас такого механизма нет, из черновиков больше всего шансов у флексибоксов). Но мейнстримом табличная верстка уже не станет, можно не опасаться.

Ух ты, такого слона я вчера замыленным глазом и не заметил . И в последнем editor's draft-е от W3C та же разница. В принципе, логика есть — W3C как бы и говорит о том, "как можно" ("что валидно, а что нет"), а WHATWG — о том, "как нужно". Хотя всё равно забавно. Может, в WHATWG-шной версии на эту тему война правок не прекращается?

IE6 и Оперу <10 (а на мое имхо, и <11) — в музей. FF3.6, если займет не больше получаса, лучше допилить, ее, про лирушной статистике, еще пару миллионов штук осталось...

Почему противоречат? Конкретно насчет таблиц, по беглому просмотру одной и второй вопиющих расхождений не вижу. Редактор у обеих вообще один и тот же Хиксон...

Про таблицы вообще я смотрел в актуальной спеке, которую предлагается "в любой момент времени считать как бы готовой": http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-table-element Про role="presentation" — было решение рабочей группы HTML в W3C прошлой весной: т.е.

Я предполагаю, что речь идет вообще о поддержке/допиливании давно существующих табличных сайтов, чтобы несчастные поисковики смогли хоть как-то выделить в них смысловую основу. Но, как показывает опыт, подобные решения "на синей изоленте" порой бывают очень живучи и временами они-то и задают вектор всей отрасли...

Пример из актуальной спеки ЖHTML/HTML5: Как видно, все перечисленные либо идут опционально, либо в количестве "ноль или более". Строго обязателен только TR. В старых стандартах надо было смотреть DTD, но сейчас это уже малоактуально. Таблицы - это не только ценный мех прочная двумерная пространственная сетка, но и куча дополнительных методов в соответствующих DOM-интерфейсах: добавить/удалить ячейку/строку, выбрать строку/ячейку по номеру... Чтобы тупо отобразить блоки сеткой, всё это богатство ни к чему, а браузер поневоле тратит ресурсы на его инициализацию и поддержку. Не говоря о том, что блочное отображение с безличных дивов так же легко убрать, как и поставить, а вот "разбить каркас" настоящей таблицы, чтобы отобразить ее просто в столбик на экране мобилки - нужно постараться, пройтись по всей "матрешке" table — tbody (тот самый "автодобавляемый", само существование которого многих удивляет) — tr — td/th, заменяя дефолтный display на нейтральный block. Конечно, пока были живы IE6/7, это всё было отвлеченной теорией, но их время стремительно подходит к концу Насчет того, что поисковикам (да и некоторым "шибко умным" браузерам типа айфонного, которые пытаются угадывать основной контент, чтобы отобразить его более крупным шрифтом типа для удобства) без разницы — новая спека, похоже, предполагает, что разница всё-таки есть (как минимум может быть). Поэтому знание про подсказки для них (типа того же rel="presentation") лишним точно не будет.

Проблемы с отрисовкой, насколько я в курсе, лечатся через table-layout: fixed, а проблемы с "семантикой", теоретически, вот-вот будут лечиться через rel="presentation". Главная проблема — нехватка гибкости. Всё-таки проще придать блокам табличное отображение где надо (если абстрагироваться от IE7, хотя и для него есть костыли), чем переопределять стили для tr/td, если, например, срочно понадобится оптимизировать эту же верстку для мобильников. Хотя и катастрофы лично я не вижу (напр., для железобетонного центрирования чего угодно где угодно). В HTML4.x обязателен tbody (хотя, если он в таблице единственный, открывающий тег для него опционален - браузер сам откроет его перед первым <tr>), в XHTML (который с application/xhtml+xml) ничего из перечисленного не обязательно (см. приложение C.11). В ЖHTML тоже вроде как tbody необязателен, но добавление tr в пустую таблицу всё равно неявно его создает (насколько я понял). Кроме того, ЖHTML теперь описывает некоторые эвристики, по которым браузеры смогут "угадать", где таблица с данными, а где чисто оформительская (напр., если есть border="0" — скорее всего она оформительская, а если есть caption, thead или th — скорее всего это таблица с данными).

А я вот в том году, типа от кризиса, впопыхах купил беззеркалку Sony NEX-3 с двумя объективами ("блинчик" 16/2.8 и штатник 18-55/4-5.6), теперь жалею, думаю продать и взять тупой банальный ультразум типа такого. Правда, уже успел ей экранчик поцарапать... но думаю, хоть за 400 условных кто-нибудь да возьмет? У нее еще год гарантии остался...

C доктайпом элементы отображаются, как написано (за редкими исключениями в уходящих браузерах). Без него — как получится Чего вы пытаетесь добиться этим? По написанному, это должно сдвинуть блок на 98px влево и на 120px вверх — видимо, аккурат за край окна...

Как-то так?

Перед девяткой пробел нужен: <!--[if lt IE 9]> — всё будет хорошо. А за <!--[if IE]> где-либо кроме демки-примера нужно бить клавиатурой по рукам Можно, но есть тьма проверенных способов сделать это же компактнее и аккуратнее 1) по ссылке "This document was successfully checked as HTML5!" 2) язык не может проходить/не проходить валидацию по определению, т.к. валидация — проверка документа на соответствие формальным правилам того или иного языка

Для начала дайте картинку, как должно быть, и пример кода, похожий на реальный. Вместе подумаем. Но я почти уверен, что одна таблица + thead/tbody где надо накроют все потребности с нюансами вместе...