SelenIT

От рваных углов, похоже, помогает конкретное значение line-height в пикселях.

У таблиц и их элементов height работает как min-height. Если в ячейке есть текстовый элемент (даже пустой!), например <p>...</p>, ячейка не может стать меньше по высоте, чем строка текста. Нужно уменьшать line-height и (скорее всего) font-size этого текста.

jdk, у вас из-за в строках 571–574 файла logisitic.css пробел в ссылке раздувается с 3 до 5 пикселей, раздвигая саму ссылку. Вот почему, кстати, не стоит злоупотреблять селекторами по тегу Простейший быстрый фикс — поставить ссылке display:inline-block, тогда пробел перестанет влиять на ширину. satantx, это что за значение, из какого стандарта/реализации?

Всё равно, имхо, даже для этой извроптимизации лучше грузить исходный svg в параллельном потоке. AFAIK, часто его вообще сразу заворачивают в скрипт, которому можно поставить async/defer и всё прочее нужное...

А как же кеширование? Имхо, нет серебряной пули, бывает оптимальное решение конкретной задачи...

Может, дело в неродном браузерном масштабе? У меня на родном масштабе всё ОК, но при чуть уменьшенном масштабе в Хроме удалось поймать «рывки» (и, что хуже, полоски от соседних картинок). Но я бы на рывки забил — при неродном масштабе такие странности простительны. А вот от полосок надо бы добавить просвета между картинками, имхо. Возможностью параллельной загрузки. Любые тяжелые ресурсы, внедренные прямо в файл, задерживают парсинг и отрисовку оставшейся его части, что особенно ощутимо на мобильных. А отдельный файл может грузиться параллельно в отдельном потоке. Поскольку у браузеров минимум 2 одновременных соединения на домен, два параллельных запроса оказываются быстрее одного очень долго обрабатываемого.

Мета-тега h1 не существует. Шрифт заголовка можно настроить с помощью CSS. Description в идеале должен быть таким, чтоб Гугл мог показывать его как текст сниппета в выдаче и юзеру хотелось туда кликнуть. По поводу остального лучше спрашивать на специализированных форумах SEOшников. Про title еще часто советуют, чтобы главное слово было в начале (т.к. в заголовке одной из кучи вкладок может быть видно только оно) — имхо, в данном случае это должно быть слово «Двери» (а-ля «Двери межкомнатные, складные, входные, двери-купе — купить недорого»), но опять же это лучше у SEOшников уточнить, я тут не суперспец.

Заодно получили еще одно доказательство, что ручная/предварительная расстановка префиксов — зло. Слава роботам типа Автопрефиксера!

и с координатами в @-webkit-keyframes и @keyframes значения для двух фонов перепутаны местами... тест на внимательность?

Можно подсмотреть, например, как это делает Ана Тудор: http://codepen.io/collection/DgYaMj/ (рекомендую просмотреть все ~80 примеров до конца, оно того стоит!)

Судя по всему, всё-таки баг файрфокса. Очень древний (впрочем, за время его существования сама спецификация менялась как угорелая, так что очень долго не было понятно, какое поведение в этом случае правильное). Может, попробовать уйти от table-* к флексбоксам?

Кроме *-break-inside, есть еще *-break-before/after, можно поиграться с ними.

А с поддержкой как? В прошлом году еще приходилось выкручиваться: .sample2 li { -webkit-column-break-inside: avoid; page-break-inside: avoid; /* Makes effect only in Firefox */ break-inside: avoid; /* IE10+, Opera 11.1—12.1 */}

Хорошие практические примеры неочевидного применения таких штук есть в этом блоге по тегу «A11y».

Просто зафлоуить нечего. Дефолтные маркеры списков в актуальном CSS никак не управляются. Вариант с псевдиками и CSS-счетчиками — самый логичный и, не побоюсь этого слова, стандартный.

Это же XML. По идее, можно подключить свой неймспейс и объявить эти атрибуты в нем (только что проверил — вроде как минимум в Хроме и Фоксе работает, отображению не мешает).

Картинке всё же float: right, наверное? Как вариант — для figcaption float: left; width: calc(100% - 150px). Но ради чего так изворачиваться?

С точки зрения браузеров XHTML 1.0 не существует, поэтому можно. И да, проверяйте новым валидатором, который ближе к реальности. Там не микроформаты, а микроданные, которые используют неизвестные в HTML4/XHTML1 атрибуты типа itemprop.

В случае предупреждений при проверке HTML5 это не совсем так. Стандарт формально соблюдается и с устаревшей кодировкой, но валидатор (точнее, «проверятор-помогатор») дает подсказку, где экономия на спичках может обернуться реальными граблями и головняком (подключение сторонних скриптов типа счетчиков и соцкнопок, интеграция с CMS, необходимость в чем-то типа htmlentities() для любого контента из неизвестного источника, и т.п.).

По блок-схеме, предлагаемой теми же «HTML5-докторами» (адаптированный перевод), выбор в пользу article делается на шаг раньше. Впрочем, если это агрегатор новостей на опред. тему, и каждая новость служит дополнительной иллюстрацией какого-то тезиса (напр. актуальности рекламируемой технологии) — наверное, может подойти и figure . А микроданные, по-моему, вполне могут ужиться и в article (в конце концов, фото в галерее — и картинка с подписью, и самодостаточная единица контента, никакого противоречия нет).

В теории, экранные читалки для слепых и т.п. будут зачитывать соотв. части страницы правильно. Напр. не просто "ссылка первая, ссылка вторая..." и так 100500 раз (в случае глубокого древовидного меню), а "Блок навигации. Пропустить?". Ну и как следствие, поисковикам тоже будет проще понять, для чего нужен тот или иной блок на странице. Как на самом деле — надо тестировать с разными комбинациями таких читалок и браузеров, т.к. бывает по-разному.

На самом деле с учетом разметки, которая вся из ASCII, разница в объеме не 70%, а от силы 20-30%. С учетом gzip-сжатия (которое для экономии трафика и мобильности куда важнее) — и того меньше, всего ничего. Зато никаких проблем со вставками любых символов из любого источника.

Есть вот такой документ с общими правилами использования aria-ролей и табличкой ролей по умолчанию: http://w3c.github.io/aria-in-html/

Мне кажется, для новостной ленты с анонсами всё-таки <article> с заголовком уместнее. Потому что такой блок сохраняет смысл и в RSS-фиде, например. А вот остальной поток контента никак к нему не обращается, в отличие от <figure>.

Возможно, для единообразия с выпадающей частью, где в зависимости от :hover предка display меняется с block на none и обратно, block везде указан в явном виде, чтоб не запутаться. Но вообще не стоит очень уж равняться на тот пример, он очень сильно устарел (напр. использует лишь старый экспериментальный синтаксис градиентов, когда все актуальные браузеры давно понимают стандартный синтаксис без префикса). Каждое в отдельности. Хотя у float есть свои особенности.