SelenIT

Возможно, поможет http://kizu.ru/fun/legends-and-headings/

Да, это я и имел в виду под специфичностью (так эти числа называются в спецификации). Но в плане скорости селектор по атрибуту заметно уступает селекторам по id и классам. Конечно, эта разница становится существенной лишь в редких случаях ну очень уж нагруженных проектов, но, имхо, совсем забывать об этом тоже не стоит

Как минимум 256 Только ради уменьшения специфичности, сильно жертвуя производительностью селектора? Имхо, нелогично. Если уж вообще использовать id в стилях, то осознанно и с умом (т.е. навешивая на него только уникальные стили, кот. не придется переопределять ни при каких условиях), для прочих случаев есть классы (самый универсальный подход), на крайняк data-атрибуты и т.д.

Ага, один префикс, наоборот, надо добавить. В 30-й строке, перед box-sizing: border-box, добавить -moz-box-sizing: border-box. Или просто подождать месяц до очередного обновления, должно и так заработать. Но вообще в наши дни верстать в Quirks mode (без доктайпа) - как-то странно. "Режим причуд" потому так и называется, что в нем браузеры имеют право трактовать CSS как придется... Имел в виду вещи навроде -webkit-transform без обычного transform следом. Если расставляет Autoprefixer или что-то вроде, имхо, всё должно быть в порядке)

В каком-то ископаемом IE, ЕМНИП, получалось обмануть браузер и закрыть окно через close(), предварительно установив фейковый window.opener. Современные браузеры не такие доверчивые, закрыть их, пожалуй, можно разве что аварийно Это проблема дизайна, а не браузера. У Фокса есть энное кол-во багов, как у всех, но в целом хорошую верстку он отображает наравне с тем же Хромом. Вы часом -webkit-префиксами не злоупотребляете? Вообще хорошо бы увидеть код, глядишь, общими усилиями отладим...

А тупо добавить общую обертку низзя?

На скорую руку придумалась такая модификация: http://jsfiddle.net/x53bQ/5/

Это специально придуманное поведение. Подробнее — http://softwaremaniacs.org/blog/2005/09/05/css-layout-flow-margins/ (после «Отчего так»).

По спецификации... Вообще, интересная задача. Как вариант, можно нарисовать границы тенями, выступающими на 1px, поверх однопиксельного border-spacing'а: http://codepen.io/anon/pen/oJced/

Раз уж тему отнекропостили, нужно упомянуть, что вместо target="newtab" можно использовать target="new", target="oldtab", target="taburet", target="oooo" и любое другое незарегистрированное имя окна. Все они открывают ссылку в окне/вкладке, которой присвоено данное имя (новой, если такая ссылка открывается впервые, и вместо старого содержимого, если это окно/вкладка уже открыто), в отличие от стандартного target="_blank", каждый раз открывающего новое окно/вкладку.

В опциях визивига должна быть возможность «подхватывать» внешние стили (для TinyMCE как-то так). Как по мне, желательно для каждого сайта скопировать туда стили как минимум контентной области, чтобы визивиг лучше оправдывал своё название.

В редакторе шрифтов должна быть соотв. опция. Иногда она находится в неожиданном месте. Напр. в популярном FontForge — на вкладке... OS/2

Проблема действительно в line-height. У инлайн-блоков она оказывается унаследованной от родителя (т.е. 50px) и текст в них пытается выровняться по центру 50-пиксельной полосы (даром что большая часть ее переполняет 18-пиксельный инлайн-блок). Нужно задать им отдельную line-height поменьше (для выравнивания текста в них), а большая line-height контейнера останется для центрирования самих блоков. Вторая проблема — межсловные пробелы между инлайн-блоками, добавляющиеся к суммарной ширине — тоже присутствует, убрать ее (задав нулевой или микроскопически малый font-size контейнеру) крайне желательно. Ну и box-sizing: border-box пока, увы, нуждается в -moz-префиксе (только с Fx29 он отпадет). Итого: http://jsfiddle.net/7WMMy/11/

document.querySelector('#Start > div ~ div')?

Скорее всего, конкретно в этом случае баг. Почему-то для инлайнового элемента учитывается концевой пробел, который, по логике, должен игнориться. Но вообще границы инлайновых элементов (особенно многострочных) при расчете position по спеке не определены, так что надеяться на милость и единодушие браузеров тут не стоит.

В любой «валидации» и «санитизации» нужно прежде всего четко представлять, валидность для чего требуется и что от чего защищается. Хорошая обзорная статья про основные виды уязвимостей в вебе и защит от них — http://www.captcha.ru/articles/antihack/. Конкретно про защиту почтовых форм — http://phpfaq.ru/mail (тот сайт вообще советую изучить целиком). Htmlspecialchars к ней отношения не имеет, но принимать от пользователя html-разметку — вообще неудачная идея (неудобно для большинства и небезопасно). Лучше принимать простой текст и подставлять в надежный html-шаблон.

Безотносительно к проблемам хостинга, функция очень, мягко говоря, странная, и сама по себе никак не помогает защитить форму от рассылки спама через нее (одна надежда, что это реализовано в классе). Мануал говорит (http://pk1.php.net/stripslashes), что работа stripslashes может зависеть от настроек. Но зачем она тут вообще?

Transform входит в стандарт, но IE9 поддерживает только его 2D-часть (с префиксом, зато рисует оч. аккуратно). Впрочем, насколько я смотрю, наклонных текстов тут совсем немного и они однотипные (действительно, можно сделать картинками), а прочие треугольники вполне можно сделать старым добрым трюком через border…

...и ей display:block

А последовательность верная? Сначала префикснутое свойство, последним стандартное? Конкретно Хром (и др. браузеры с автообновлением, включая Фокс) — имхо,смысла нет, за 3-4 месяца такие версии уходят полностью. Но -webkit-префикс (с предпоследней версией синтаксиса, уже без color-stop-ов, но еще без to и at) по-прежнему актуален для мобильных браузеров, прежде всего для Андроидов.

Не только: http://caniuse.com/#feat=css-gradients

Если ничего не путаю, firefox убрал поддержку -moz-префикса для градиентов через несколько версий после того, как стал поддерживать беспрефиксный стандартный. Сейчас префикс неактуален, спасибо автоапдейту. Колорзилловский генератор добавляет очень много лишнего, типа -ms-префикса, нужного лишь для ранней беты IE10, которой не пользуется ни один живой человек Устаревшие браузеры, как правило, работают на устаревшем железе, и для их юзеров куда важнее, чтоб они работали мало-мальски быстро, а не рисовали неимоверную красоту по нескольку минут. Изящная деградация рулит!

Логично, no-repeat — недопустимое значение свойства content.

Ой, я ж забыл, что IE9 понимает трансформы (с -ms-, наверное, единственный реальный случай, когда этот префикс нужен). С ним вроде совместимость почти та же.

Вот такое решение не поможет?