SelenIT

Почему?

Это требование синтаксиса XML, в HTML(5) оставлено ради обратной совместимости с XHTML (HTML, переписанным по XML-правилам). В SVG-тегах типа <path/> необходим (т.к. SVG — подмножество настоящего XML), в одиночных HTML-тегах (<img>, <input>, тот же <link> и т.п.) необязателен, но и не мешает, так что это во многом дело вкуса. Бывает полезен при работе в средах, использующих XML-парсер (напр. для правильной подсветки кода в редакторе на JSfiddle:).

Нужно решать через CSS. Как и в случае др. чисто визуальных атрибутов (color, align/valign, cellspacing/cellpadding и т.п.).

Я так понял, что сам Брюс не понял, почему Эпл внесла это в HTML. Но раз уж случилось так, то внутри HTML единственное место, куда его можно было внести — это внутрь head (т.к. при уже начавшемся выводе и отрисовке body адаптировать этот вывод к вьюпорту уже поздно), а единственное, что можно безболезненно вставить в head — это meta (хотя по семантике оно здесь явно не подходит).

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

alexriz, а как? Заинтриговал..

А вот нужен ли сейчас общий враппер для поддержания цепочки 100%-ной высоты? Не пора ли уже ставить контейнеру прибитого футера min-height:100vh, а не понимающим этого динозаврам давать изящно деградировать?

Строго говоря, фон, даже если он задан для body, на самом деле применяется к html (если только для html не задан свой отдельный). Но вот многие сторонние скрипты всяких всплывашек, выпадушек и и.п., действительно, отсчитывают координаты от document.body, так что злоупотреблять скукоживанием body и впрямь не стоит. На проекте для себя можно всё

Могу порекомендовать занятный ресурс http://real-english.ru/ (особенно этот и этот материалы, ну и этот можно распечатать как шпору ).

Я - да.

Валидатор предупреждает, что это экспериментальная функция валидатора (поскольку стандарт языка, хоть его первая очередь уже на 99% утверждена W3C, всё же еще может меняться и дополняться). Браузеры, включая IE6, понимают этот доктайп правильно (переходят в стандартный режим). А современные браузеры (новее 2011 г. выпуска), действительно, разбирают любой HTML по правилам HTML5, поэтому сейчас нет особого смысла пользоваться другими доктайпами

Если не указывать доктайп, они еще не то поддержат (даже размеры без "px" и hex-цвета без "#":). Обратная, так ее, совместимость с тучей не желающих умирать реальных страниц, сделанных в 90-е или позже, но в том же стиле... Можно пример задачи, которая "удобно и элегантно" решается на разбитом экране? Ни модальное окошко на весь экран не развернуть, ни расширить рабочую область, если в ней станет тесно, об адаптивности и мобильных юзерах лучше вообще не вспоминать. Юзер видит в адресной строке один адрес (ничего не значащий), по факту работает с другим. Для элементарного взаимодействия между навигацией и контентом (типа подсветки активного пункта) приходится городить скрипт. Проблему поисковиков тот же скрипт не решает, а в лучшем случае костылем заметает под коврик - как была половина ключевиков в одном документе, а половина в другом, так и осталось. Вдвое больше запросов к серверу, вдвое больше памяти на объекты браузера, путаница с разными глобальными объектами для скриптов, фиг кроссбраузерно застилизуешь пространство между фреймами... В конце концов, если уже никак без вставки одного HTML в другой, есть же <iframe> - тот же фрейм, но действительно гибкий и удобный (может быть вставлен в любое место любой части страницы, динамически отресайзен при необходимости, перекрыт другим элементом и т.п.). И поддерживаемый не только браузерами (тяп-ляп и чисто ради традиции), но и актуальным стандартом.

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

Скорее всего, дело в дефолтном отступе самого body (margin:8px). Обычно его сразу обнуляют. Это было справедливо для HTML 4 Strict и XHTML 1 Strict. В HTML5 это уже необязательно. Но злоуплтреблять не стоит, конечно

По умолчанию тег элемент P наследует стили родителя (напр. BODY), но добавляет верхний и нижний margin-ы (обычно по 0.75em). Они схлопываются, поэтому разницу между P и "голым" текстом рядом с ним можно и не заметить. Но если понадобится, скажем, поменять только для этого текста шрифт, то в случае P это элементарно, а в случае "голого" текста единственный выход - менять шрифт у BODY, а потом отменять обратно у всех других его потомков. Поэтому если речь именно о смысловом блоке текста, использовать P (или какой-либо его осмысленный заменитель, напр. ADDRESS) крайне желательно. Не говоря о том, что текст, правильно разбитый на отдельные абзацы, лучше воспринимается поисковиками и вспомогательными технологиями (по сравнению с "первобытной" версткой, имитирующей абзацы BR-ками). Если же текст никак не сгруппирован по смыслу и больше в контейнере ничего не предполагается, конечно, P не нужен.

Спецификация и DOM-инспектор в браузере. У P может быть только текстовое или «текстоподобное» (phrasing) содержимое, а закрывающий тег для него необязателен. Поэтому перед любым «блочным» элементом, включая другой P, он неявно закрывается автоматически. Это стандартное поведение.

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

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

«Что позволено Юпитеру...» Валидность — не панацея и не гарантия, да. И у гигантов вполне могут быть весомые причины, более важные, чем валидность: экономия трафика, поддержка странных браузеров (на их объемах даже смешные проценты выливаются в изрядные абсолютные числа), корпоративные фреймворки и компоненты, облегчающие разработку и поддержку большими распределенными командами... К томе же гиганты, по совместительству являющиеся поисковиками, не так остро озабочены SEO (ходят упорные слухи, что валидность страниц является там преимуществом, хотя доказательств немного). У фрилансера, теоретически, тоже могут быть такие веские причины, объясняющие каждую красную строчку в валидаторе. Но на одного такого фрилансера-аса найдутся десятки и сотни халтурщиков, у которых ошибки валидности — результат обычных лени и незнания. Вот заказчики и страхуются...

Каждая пара чисел — это X- и Y-координаты очередной точки. Тот же принцип, что для coords у <area shape="poly">.

Это всё как раз потому, что document.body в стандартном режиме не похватывает размеры окна браузера, а растягивается по контенту. А поскольку контент в данном случае - сама картинка, плюс еще у body, скорее всего, есть дефолтные 8-пиксельные padding-и, плюс под картинкой 5-пиксельный отступ из-за display:inline; vertical-align:baseline, то и получается, что при каждом событии картинке присваивается высота, где-то на 20-21px больше предыдущей. Попробуйте вместо document.body отталкиваться от document.documentElement.

Простейший вариант - раздельные контейнеры. Для меню 2 контейнера, внешний на 100%, внутренний на "основную" ширину. Для основного контента один контейнер на "основную" ширину. Если этот вариант по какой-то причине не подходит - надо смотреть по ситуации (какой у меню фон, какие браузеры нужно поддержать и т.д.), вариантов много, но у каждого свои ограничения.

По стандарту размерности длины должны указываться с единицами измерения (кроме нуля, ноль в любых единицах ноль, поэтому для него единицы можно опускать). В стандартном режиме отображения размеры без единиц считаются некорректными значениями и игнорируются (независимо от способа задания - стилями или скриптом). В Quirks mode браузер включает режим телепатии "что хотел сказать автор", и воспринимает такие значения как указанные в пикселях. Вторая проблема - в Quirks mode элемент body по умолчанию подхватывает высоту вьюпорта, в стандартном режиме он по умолчанию имееет высоту контента, а высоту вьюпорта подхватывает корневой элемент (aka html, аka document.documentElement).

Упс, слона-то я и не приметил. Видимо, не ждал такой подлянки от учебника. Наверное, есть смысл выбрать другой учебник

А файлик style.css не забыли подключить? По логике, там должно быть что-то html, body { height: 100%; }. В предисловии или еще где-нибудь это не оговорено?