SelenIT

colspan и rowspan на дивах, к сожалению, не делаются. Делать таблицы на дивах несемантично

Не слушайте их. Ячейкам тоже всегда можно сменить display на block при надобности.

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

Нету такого. И вряд ли в ближайшее время появится. Ведь, чтобы распечатать файл, его всё равно сначала нужно скачать, а после скачивания он автоматом откроется соотв. программой и уже будет управляться из нее...

Похоже, что нельзя: Разбор идет строго по порядку в коде и dd объединяются в группы с предыдущим dl, а не со следующим. Но часто можно изменить визуальный порядок силами CSS (float, direction и т.п.)

Всё-таки в первую очередь браузер определяет это на основании HTTP-заголовков, отдаваемых сервером (да, MIME-тип). Атрибут тега — вещь уже вторичная и вспомогательная (а в HTML5 и вовсе необязательная). Для этого есть классы и CSS. У кнопок есть некоторые ограничения (их нельзя заставить вести себя как при display:inline), но помимо этого кнопки и ссылки сейчас прекрасно стилизуются друг под друга без насильного противоестественного скрещивания

Может, самописный сервер не тот Content-type отдает? Не text/css, а text/plain или, того хлеще, text/html?

Собственно, подумал, что как раз для этого случая (внутри nav только два блока, который должны быть рядом по горизонтали) логичный быстрый фикс — поставить на nav display:flex. Flex у контейнера отменяет float у непосредственных потомков, поэтому в современных браузерах будет работать предсказуемо. А в старых будет, как и раньше, работать плавучая магия

Даже в таком состоянии он прекрасно поддерживает и инлайн-блоки, и display:table-* без костылей. ...но лишь если не подходить близко и не дышать. О том и речь: плавающий блок без заданной ширины, на ширину которого влияют плавающие блоки внутри него — карточный домик, который может рухнуть от малейшего ветерка даже издали. Спецификация для этого случая написана так, что целый W3C без бутылки не разберется, в официальных тестах на поддержку CSS эта ситуация упущена, поэтому браузеры могут (пока) трактовать ее как хотят получается. Не надо особо полагаться на такие конструкции. Наглядный пример, подтверждающий ту статью)

У браузеров есть проблемы с определением ширины плавающих элементов со вложенными плавающими элементами. Что удивительно, лучше всего (по букве и духу стандарта) себя ведет как раз IE (и Опера Престо, мир кешу ее). Firefox не учитывает ширину вложенного флоата при обсчете текста внешнего, а Хром, выходит, и с двумя вложенными флоатами разобраться не в состоянии. Мораль — не надо использовать float для всего (см. п. 11 здесь)! Для размещения элементов по горизонтали хватает других способов — флексбоксы (работающие уже даже в Опере Мини!), инлайн-блоки, display:table-cell на худой конец....

Если вы хотите то проблема скрытия заголовков, возникать не должна. Аутлайн — не цель, а средство. Логические структурные элементы типа <section> — тоже. Использовать их для визуальной, а не смысловой, группировки спецификация прямо запрещает, а вот оставлять их без заголовка — всего лишь «не рекомендует». Хорошие мысли про семантику есть в этой статье (в частности, в разделе про поисковики). И учитывайте, что многострадальная outline пока толком нигде не реализована, так что из HTML5.1 ее еще и убрать могут...

А слой уже растеризованный? Может, там векторные формы невзначай сохранились?

Вот, честно говоря, тоже в самом по себе <header class="header"> ничего крамольного не вижу. Ну забавное совпадение — как если человек по фамилии Столяр действительно работает столяром. Так и тут: на данной странице логический блок с вводной информацией еще и оформлен как шапка — прекрасно. На другой странице шапка может состоять из единственного заголовка или быть по совместительству верхним меню, и там вместо <header class="header"> может появиться <h1 class="header"> или <nav class="header">, при этом структура страницы будет соответствовать ее логике, а внешний вид не изменится. Другое дело, что имя класса, конечно, лучше бы взять понагляднее — напр. page-header или general-header. И третье дело, что эти навороты и впрямь едва ли пригодятся лендингу-однодневке

В Jade, но не в HTML. Jade — удобный и полезный инструмент, безусловно, но на выходе у него всё равно HTML, поэтому от ответственности за несоблюдение правил HTML он не освобождает Не глюк, а специфицированная особенность стандарта. При желании, да, обойти (и «впихнуть невпихнуемое» насильно) можно, скриптами и не только. Но зачем героически преодолевать трудности, которых можно себе просто не создавать? Упрощение и унификация в 99,9...% случаев. Куда должен перейти браузер при клике по вложенной ссылке — по внешней, по внутренней, открыть вторую вкладку и по обеим? Ну и исторические причины со времен, когда многие теги рассматривались не как контейнеры (а-ля скобки в математике), а как разграничительные маркеры (а-ля знаки препинания и «красная строка» в естественном языке), тоже. Ну и многострадальная семантика, куда ж без нее: если абзац по смыслу — некий единый смысловой блок из нескольких фраз текста, как он может включать другие абзацы? Тогда он автоматически перестанет быть абзацем и станет более крупной структурной единицей (section, blockquote, figure или просто div — по ситуации).

Ничего, мы напомним doctype htmlhtml(lang="en") head title Oops style .test { color: blue; } | .test .test2 { color: green; } | body > .test2 { color: red; } body h1 Jade — хорошая вещь, но не заменит голову... p.test Вот как бы абзац p.test2 А это как бы внутренний абзацик... | | и как бы продолжение первогоМожно по-быстрому проверить в песочнице (и заодно удивиться подсветке последних закрывающих тегов), ну и скомпилированный код тоже

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

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

В p можно вкладывать только фразовый контент (простой текст и то, что раньше называлось «строчными элементами»). И стоит помнить о необязательности закрывающего тега для него — часто бывает, что закрытия тега не видно, а оно есть

Ругается на закрывающий тег </p> без соответствующего открывающего. Потому что предыдущий открывающий (строка 61) в полном соответствии с любым HTML-стандартом неявно закрыт перед заголовком h4 (см. http://www.w3.org/TR/html5/syntax.html#optional-tags). Абзацы — не универсальные контейнеры (как div), а скорее логические «разбиваторы» для текста, в них не может быть вложенных блоков.

Значит, что некоторые элементы оказываются шире окна и из-за них появляется горизонтальный скроллинг. А контейнер с фоном как раз подстраивается под ширину окна и оказывается уже страницы. Кроме вышеуказанного, там еще есть и таких элементов на странице множество...

А зачем выключать отображение скрытых и убирать атрибут? Сразу скрытый файл разве не редактируется?

В принципе, существует вот такой финт/хак, чтобы это обойти. Но да, с JS проще и логичнее, всё-таки это уже конкретное поведение, а не просто состояние.

Так делать нельзя, разумеется. head и body на странице могут быть только по 1 шт. каждый, любые повторы этих тегов игнорируются как ошибки (более того, если до первого <body> попадется голый текст или какой-либо тег помимо <title>, <meta>, <link>, <style> и <script> — перед ним автоматически неявно закроется </head> и откроется <body>, все последующие теги станут потомками <body>, а не <head>, а настоящий тег <body> опять же будет проигнорирован как ошибочный). Все элементы попадают в общую DOM, и стили между ними никак не разделяются, так что если стили присвоены тегам, может быть много сюрпризов. Увы, переписать придется

Судя по всему, line-height должен быть не меньше, чем font-size, умноженный на дефолтную высоту шрифта, прошитую в его метриках (там обычно жутко дробный множитель навроде 1,328). Насколько я могу судить, тень в Фоксе берет большее из них и в случае дроби не округляет, а пытается "сгладить". Вообще это выглядит как явный баг, надо бы пожаловаться в багзиллу... Как временное решение, рыжего зверя еще можно попытаться укротить вот так.

Как вариант, можно сделать что-то типа var rng = new Range(), rects;rng.selectNodeContents(document.querySelector('.наш-элемент'));rects = rng.getClientRects();// console.table(rects);for (var i = 1; i < rects.lenght; i++) { if (rects[i].left < rects[i-1].left) { // тут был перенос строки, можно нарисовать что-нибудь в координатах // rects[i-1].top, rects[i-1].right и rects[i].top, rects[i].left // ...но стоит ли овчинка выделки? }}