SelenIT

Не успел появиться, уже убрали, больше года назад. Теперь HTML5 советует размечать диалоги как-то так.

Вот в этом куске (в конце раздела про лок. хран-ще):

Мелочи, за которые сходу глаз зацепился: - в разделе про клиентское хранилище почему-то (видимо, при копипасте) затесалась проверка Canvas API; - "Видеоформаты", имхо, лучше писать слитно (или, если уж раздельно, то "форматы видео"), иначе совсем калька; - Placeholder text как "подсказывающий"... ну, не знаю. Лично у меня "подсказывающее" в HTML ассоциируется со всплывающими подсказками (title). Но адекватного эквивалента сходу тоже не придумывается ("текст-затычка" грубо... "текст-заглушка" приемлемо, но далековато по смыслу... "замещающий текст" уже занято alt-ом... "подпись незаполненного поля" слишком длинно...); - Finally как "окончательно" (в проверке Canvas API) не звучит, лучше "наконец" (как в следующем разделе). И вообще фраза "используется прием двойного отрицания для перевода..." слишком тяжеловесная, не лучше ли "приводим результат к булевскому типу с помощью приема двойного отрицания"? Еще кое-где встречаются порядок слов и отдельные запятые, явно оставшиеся от англ. варианта, но это совсем пустяк. А вообще перевод отличный, большое спасибо за эту работу! P.S. Я бы предложил "локализовать" профессора Маркапа как "профессора Разметко"... но готов признать, что это слишком рискованно

Да. В них она дает точно такой же эффект, что Strict-доктайпы HTML 4.01 и XHTML 1.x.

Ничего, у меня то же самое (если не хуже), только на CSS3

Уже факт. По крайней мере, браузеры с HTML5-парсером точно не будут. Безусловно, особенно "на безрыбье". Но для глубокого понимания спеки этого мало (пример с <ins>/<del> я уже привел, еще масса нюансов с возможными значениями атрибута rel и т.п.)

Ну да. Зато нужная обрезка получится автоматом

Как вариант — использовать в качестве подложки flash со scale="noborder" и картинкой в качестве единственного содержимого.

В CSS3 можно через селектор части атрибута (div[id^=name]). Но IE7 (и более старые) курят в сторонке. Дать единый класс — универсальнее (пока) и вообще логичнее.

Всё так. Единственное назначение доктайпа в HTML5 — заставить браузеры отображать страницы по стандарту, а для этого такой минималистичной записи достаточно.

ЕМНИП, IE читает — для XML-страниц с text/xml. И даже валидирует, начисто зарубая невалидные (а не просто невеллформные, как др. браузеры в XHTML-режиме) файлы. Во всяком случае, раньше такое было. Но вообще DTD — пережиток середины 90-х. Что там семантика, добрую половину синтаксических ограничений спеки (типа "<ins> и <del> могут содержать только строчные элементы, если находятся внутри строчного элемента") он выразить не может (вот и возникла манера оборачивать блочные эл-ты в ins/del для вставки в строчные — в грубое нарушение спецификации, но с сохранением формальной "валидности" по DTD!), кроме того, один и тот же документ можно распарсить по разным правилам (тот же XHTML — живой пример) и намертво пришитая схема становится скорее источником путаницы. Просветленные искатели дао разметки давно отказались от убогого DTD в пользу conformance checker-ов на базе реального парсера (а-ля validator.nu)

А чекбоксы и радиобаттоны под таким делом нормально себя ведут?

<button type="button"> По дефолту у button-а type="submit". Только в IE это не так.

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

Фоновые потоки/вычисления?

Логично, кнопка-то, поди, type="submit", а не type="button"... или вообще button... Для подстраховки можно все варианты учесть, как в первоисточнике: button::-moz-focus-inner, input[type="reset"]::-moz-focus-inner, input[type="button"]::-moz-focus-inner, input[type="submit"]::-moz-focus-inner { border: 0; } button:focus, input[type="reset"]:focus, input[type="button"]:focus, input[type="submit"]:focus { /* не забыть поменять цвет/картинку, в общем, как-то дать понять юзеру, что кнопка активна */ } Только уж onclick тогда хотя бы. Чтобы клавиатурников совсем уж жизни не лишать...

К сожалению, не прокатит — десктопные маки тоже надо охватить... И, имхо, в фильтре для айфонов пора ставить max-device-width не 480px, а 960 — чтобы и 4-й охватить (удачно сложилось, что у айПада всё равно больше).

this.offsetParent.offsetHeight - 250 + "px"?

Скрипты привлекать ради такой мелочи не хочется... по-хорошему, конечно, хотелось бы разобраться в причине и пофиксить именно ее, но если уж без костылей никак — то отделаться минимальными... А насчет "некузяво" — это, по-моему, довольно известный "мем", авторства Людмилы Петрушевской (из сказки начала 80-х про "бутявку")...

Столкнулся с очередной траблой при внедрении кастомных шрифтов: на эпловских устройствах (включая Мак-мини) они позиционируются по вертикали по-другому (ближе к верху строчного бокса), чем на виндовых машинах. Из-за этого заголовок с плавающей иконкой под маком/айфоном/айпадом выглядят некузяво (словно иконка вниз сползла, хотя по факту, наоборот, вверх уполз заголовок). Игры с line-height и vertical-align не помогают — на маке всё равно всё по своему. Не вижу иного выхода, как явно подпереть одну из платформ специфическими для нее отступами, но столкнулся с проблемой: как в CSS опознать платформу? Встречающиеся в поиске решения нацелены либо на движок Webkit (что мне не нужно, т.к. под виндами он ведет себя вполне адекватно, а FF под Маком как раз проблемит), либо опираются на особенности мобильных айДевайсов (screen only and -webkit-что-то), не захватывая десктопные Маки. Можно ли всё-таки определить с помощью CSS-хаков именно платформу? Возможно, легче будет, наоборот, отличить винду от остального?

Кнопка "i" на коте не работает, выкидывает JS-ошибку "функция не определена" (FF 3.6.11). И для стандартного времени, имхо, привычнее запись а-ля "15:09:05" (про метрическое не знаю, как там принято. Ну и, совсем имхо, получать кол-во миллисекунд с начала текущего дня чуть проще а-ля ((now = new Date()) - new Date(now.getFullYear(), now.getMotnth(), now.getDate(), 0, 0, 0)), чем через серию умножений. Впрочем, в обоих вариантах остается проблема летнего/зимнего времени — как, кстати, она решается в метрике?

Если бы это был настоящий XHTML (с типом контента applcation/xhtml+xml), стиль должен был сработать бы несмотря на невалидность такой конструкции. Но с обычным типом контента (text/html) XHTML-код разбирается браузером как обычный HTML, по тем же правилам. Можно посмотреть в DTD используемого стандарта: ol входит в группу lists, которая, в свою очередь, входит в группу "block" (двумя строчками ниже).

Это заблуждение Посмотрите DOM страницы в файрбаге, потом проверьте код в валидаторе. Если вопросы останутся, ответ здесь.

Только, если нумерация, то, имхо, логичнее использовать список ol, а не ul...

Кажется, нашел (благодаря наводке из Гугла): Похоже, то, что надо. Странно, что более новых ссылок не попадается. Upd.: магия действует (прописал для body с none), да, это то, что надо!