SelenIT

Безымянные (анонимные) боксы. C дефолтными значениями (margin/border/padding — по нулям, width — auto, etc.)

Неправда.

Для шрифтов практически так и есть (не считая нюансов округления и реакции на смену Text Size в старых IE, ЕМНИП). Но топикстартер спрашивала о размерах блоков...

Мне одной из первых ссылок выдало раздел FAQ этого сайта. Но на мой взгляд, все перечисленные там методы страдают общей проблемой — делают текст недоступным, если CSS включен, а картинки по какой-то причине не(до)загрузились. Лично мой выбор — метод Нэша, доработанный Николасом Галлахером и нашим форумным коллегой

Да, так более правильно с точки зрения структуры DOM. Насчет кода — 1) document.getElementsByTagName возвращает коллекцию элементов по тегу, а не один элемент (надо document.getElementsByTagName('menu')[0]), 2) функция-обработчик не знает переменной elem, нужно или делать ее глобальной (быстро, но коряво), или использовать замыкание (сложнее, но лучше).

Да, но для высоты надо будет проставить значения всей цепочке родителей, вплоть до html. Так же, как шрифт текста.

Может быть, не полная правда, что лучший. Но что друг — правда наичистейшая. Запихивать HTML-элементы в места, для них не предусмотренные — всё равно, что засовывать что-либо в живых котят, в брюшную полость мимо желудка. Это отягощает карму и рано или поздно аукнется "необъяснимыми" и суровыми проблемами со скриптами и не только (в первую очередь в IE и Опере).

По спецификации <menu> — список команд. Команда — введенная в HTML5 абстракция, объединяющая кнопки, ссылки, опции select-ов, чекбоксы, радиобаттоны и всё такое прочее (всё, что при нажатии выполняет какое-то действие или меняет состояние). У этого <menu> тёмное и запутанное прошлое. 300 15 лет назад, когда компьютеры были механическими большими, а веб использовался преимущественно для научных статей, <menu> и <dir> были аналогами <ul>, только "заточенными" под списки ссылок и файлов на диске соответственно. В этом качестве они не прижились, очень много лет оба были вне закона. Потом <dir> вымер напрочь, а <menu> нашел применение в веб-приложениях. Контекстные меню уже работают в Файрфоксе. Но дефолтное оформление в виде UL-списка — скорее всего следы его "бурной молодости", когда он был чисто презентационным элементом. Неправда. Прочитать ее, хотя бы со словарем, не так уж трудно. Вот разобраться в ней — да, задача... В HTML5 нет блочных элементов. Есть секционные, структурные, текстовые, интерактивные и т.п. — в зависимости от назначения, а не от типа отображения. "Улучшать семантику" элементы не могут. Они могут ее иметь (то самое назначение) и использоваться либо семантически (в соответствии со своим назначением), либо как попало (не по назначению). Если нет уверенности, что использование элемента соответствует его назначению — имхо, меньшим злом будет использовать вместо него что-то семантически более нейтральное (хоть те же дивы).

Скорее всего, не по незнанию (вернее, не только), а по умолчанию для интранета. X-UA-Compatible="IE=Edge" должен был спасти ситуацию)

Да, признаю, погорячился. Только в FF работает (где :placeholder — псевдокласс).

В тех браузерах, где стилизуется на уровне границ и фона — можно попробовать тупо перекрыть им незаполненный контрол (визуально). В остальных, увы, ничего не даст. Единственное, что вообще пришло на ум по теме из мира (около)CSS.

Мне таковые, к сожалению, неизвестны. То, что скрипт достает финальное значение ("used value") в пикселях — увы, документированный факт... Хотя файрбаг со товарищи достают как-то. Мне приходит на ум только вариант тупо парсить все доступные cssRules и проверять (напр. через querySelectorAll), что подходит к элементу, а что не подходит. Интересно, так они делают или есть путь рациональнее...

Как временное решение — сделать тупо два блока, один в другом. Снимать высоту у внешнего, присваивать внутреннему. Но я тоже пока плохо понимаю, зачем такие манипуляции нужны...

Разница в пунктах и пикселях в CSS есть всегда. Три пункта равны четырем пикселям. Спор был о соотношении пунктов в фотошопе с пунктами в CSS.

Пиксели практически совпадают. За вычетом нюансов отрисовки/сглаживания (текст может казаться более или менее жирным чем на макете и т.п.).

Как переделать уже готовый макет — сам не знаю. При создании нового файла есть поле "Resolution", туда можно ввести любое число (по умолчанию обычно либо 300 dpi — типичное разрешение для полиграфии, либо 72 — историческое маковское). 12/(3/4) = 12/3*4 = 16. Но это кегль шрифта — высота кегельной площадки, где предусмотрено место не только для заглавных букв, но и для всяких "хвостиков" и "закорючек" выше и ниже (выносных эл-тов и диакритических знаков). Размер самих букв может быть разным в разных шрифтах (но не больше кегля). Обычно строчные буквы — в районе 0.4–0.5 кегля, заглавные раза в полтора больше.

Должна растягиваться, если явно этого не запретить через user-scalable=no с его друзьями. Только нужно учесть, что размеры вьюпорта на всех мобильных девайсах считаются особо хитро...

Валидный-то он валидный. Но, возможно, не оптимальный из валидных вариантов (хотя более удобный в поддержке)

Строго говоря, ситуация, когда IE совсем-совсем не актуален — вроде бы не совсем фантастика. Но редкость, конечно, невероятная.

До сих пор не могу простить DW его мелкое самовольство типа замены неразрывных пробелов обычными. Очень мешало жить при коллективной работе над одним документом и вынуждало использовать архаичные подстановки , даже если вся верстка была в UTF-8. Aargh!

Единственный вариант, который приходит на ум — поиграть со стилизацией атрибута placeholder (если верить этой таблице, в FF и Сафарях для него можно нарисовать рамку и фон). Но это от отчаяния и чисто ради принципа, о кроссбраузерности речи не идет. К сожалению, CSS позволяет различать только ключевые состояния (чекнуто/не чекнуто, активно/не активно, валидно/не валидно и т.п.). А все значения необязательного поля (включая пустоту) абсолютно равноправны — для логики оформления это одно и то же состояние. Различие между такими значениями — это уже логика поведения/функциональности, и в скрипте ей самое место (как раз для этого там предусмотрены два DOM-свойства value и defaultValue, а не один атрибут value). Возможно, я ретроград, но на мой взгляд делать это скриптом не только удобнее, но и логичнее.

Как выше подсказали — в инструментах разработчика. Нет. Более того, в новых FF и Хроме размер заголовка зависит от уровня вложенности секции. Смотря по задаче. Для промо, где текст привязан к пиксельной графике — явно выигрывают px. Для информационки, где всё строится на тексте и вокруг него — может быть уместен em (или его продвинутый аналог — rem). Но с пикселями проще управляться, а проблем с их масштабированием уже нет. Так считалось несколько лет назад, но сейчас это спорно. И вообще w3school — не самый авторитетный источник (они не связаны с W3C, фактически самозванцы). Так. Фотошоп исходит из 72 пикселей на дюйм (так было в 90-х на Маках). По стандарту CSS, в дюйме 72 пункта, но 96 пикселей (так чаще всего получалось в реальности, когда стандарт писали). Если в фотошопе выставить 96dpi, то и пиксели, и пункты будут соответствовать CSSным (но рендеринг шрифтов всё равно может отличаться). Да. 1px = 3/4pt = 1/96in. По умолчанию (если не переопределять font-size для body) в соврем. браузерах 1em = 12pt = 16px = 1/6in. Да. Пункт — старинная типографская мера, 1/72 дюйма (примерно 0.35 мм). Скорее всего так.

Имхо, ради "тех. описаний изделий" — слегка оверкилл . Да и с кроссбраузерностью менее шоколадно...

Если речь о взаимодействии с XML — однозначно лучше код. Мнемоники должны быть определены в DTD или чем-то похожем, по умолчанию XML их не знает. А код работает всегда.

Имелась в виду разница между FF3.6 (вымирает, но очень плавно) и любым последующим FF. Аналогично с вебкитными, на десктопах-то старых хромов уже нет, но в мобильном зоопарке возможно всякое (напр. андроиды 2.x еще живее всех живых). Опера парсит секции уже по-новому, но заголовки рисует еще по-старому — опять же это может скоро измениться. Фишка нормалайза именно в том, что не нужно учитывать (потенциально) неограниченное множество вариантов — все самые актуальные для отображения свойства (размеры/поля/отступы) явно прописываются с типичными (а еще лучше — нужными по дизайну) значениями. А всякие новые и редкие свойства (особенно префикснутые) пусть будут себе, как авторам браузера взбредет — если они себе не враги, отображение от этого вряд ли пострадает...