Viper

По этому поводу хотелось бы дополнить: в конец body стоит подключать в том случае, если скрипты являются маловажным дополнением, относительно контента(DOM структуры) - рекомендуется в большинстве случаях. В head - когда скрипты являются основой страницы, например, js карты, ИМХО.

Несколько популярных мифов о HTML5: _http://habrahabr.ru/post/140155/

Ну что тут сказать... То ли это троллинг, то ли человек только начал изучать HTML5. Решил, что он мего-гуру) и может нести бредистину в умы своих последователей... Из контекста: "мое ИМХО - есть истина, слушайте только меня и тд..." Не советую читать статьи таких "гуру". В статье заметно, что он опирался на данные, статьи и цитаты 2-3 летней давности... Чего только стоит его "Создание стилей для заголовков в HTML5" и заявление - "ведь на данный момент почти никто не поддерживает HTML5-структуру документов"... Так же советую прочитать(рассуждения) сначала статью "Наша бессмысленная погоня за семантической ценностью", а после нее эту - "Ценность осмысленности". Возможно они помогут тебе определиться насчет поддержки семантики.

Посмотри как у меня сделан элемент close - это должен быть другой элемент, который заменяет объект-open и является "визуальной обманкой". Именно так, пускай он и будет при этом такой же на вид как и open(твоя стрелочка).

Это пока-что... И смотря, что подразумевать под "семантикой") Именование классов, например, тоже "семантика", которая помогает разработчикам так же, как и логичная "чистая" структура... Новые атрибуты для полей ввода тоже "семантика", которая в скором времени заменит клиентскую валидацию и тд...

в iOS, то есть, на mac'е? А браузер то какой? Выложи код на http://jsfiddle.net , что бы не гадать в слепую в чем ошибка... Возможно, элемент закрытия - "стрелочку" неправильно реализовал...

Да, но я спрашивал(мой комментарий был) про <header>, а именно использование его как контейнера для Единого тега-заголовка. Именно это есть ошибкой. Да, нету. Поторопился: думал, что у них стоит общий артикл, который разбил на разделы... Но у них нету общего контекста ко всем разделам(section), по-этому и не вставили в article. У них каждый раздел(section) является равноценным самодостаточным объектом. И заметь, они не обрамляют другие структурные теги и они не находятся в каком-то общем теге <section>.

Можешь кинуть номер страницы, где про такое говориться? Мягко говоря, удивлен...) Ну это еще не фактор, позволяющий воспринимать за правило Семантика, и даже ее отсутствие, вообще не есть критично) _http://css-live.ru/articles/blochnyx-i-strochnyx-elementov-v-html-bolshe-net.html Да, можно Посмотрел код по твоей ссылке: там <section> использован по всем правилам и логично. Хороший пример. Но ты видимо не понял логику его применения. С помощью <section> они разбивали статью(article) на разделы(section). А не использовали в качестве врапов и не разбивали с помощью них сайт на блоки/секции, как у тебя...

1. Только 1 вразумительный/логичный header. Все остальные лишние - бессмысленные. Не нужно заголовки обрамлять в header. 2. Поле поиска - семантичнее указать type = search 3. Интересует семантика, но не использовано article и figure... 4. Перебор тегов section. Они не для обрамление, они не замена wrap'ов. И они не служат для построения сетки сайта из блоков/секций. П.С. Ты построил дом, в котором десятки бессмысленных, крошечных, не удобных комнат, которые только занимают все место, но абсолютно не пригодные для использования, ИМХО.

Реально, даже если и не очень простые А с zen codding и фреймворками и за 1 час клепать можно) Но да, это не страницы сложных проектов и очень страдает качество...

_http://refresh-sf.com/yui/ _http://www.cssminifier.com/ Все зависит от проекта и задач... Вес, например, 100Кб в сжатом виде считаю нормальным, ИМХО. Ты должен понимать, что на скорость загрузки влияет как вес файлов, так и их количество. Нету единого правила для всех проектов, как нужно оптимизировать стили. Разве-что, кешировать и сжимать их полезно всегда)

Параметр Padding'а не входит в вычисление размеров элементов. То есть, если у тебя в CSS прописано для элемента, например, height: 50px; и padding-top: 15px, то высота элемента будет = 65px. Тоже относиться и к border. Свойство box-sizing(-moz-box-sizing для FF) со значением - border-box, позволяет добавляться padding и border к заданному параметру высоты/ширины.

An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images. Несколько популярных мифов о HTML5: _http://habrahabr.ru/post/140155/ _http://code.google.com/p/html5shiv/

Атрибут "alt" в теге <img> обязателен, так как <img> - контент-изображение, которое должно нести в себе информационный смысл. Все остальное(элементы дизайна) должно делаться средствами CSS - это если по "правильному") Но не стоит на этом фанатично зацикливаться ИМХО

Вы про IE6? Вы его еще поддерживаете?) Не считаю, что какой-то из вариантов - не правильный, ИМХО. Применение зависит от ситуации, необходимости. Первый вариант можно применить всегда, тогда как второй - зависит от дизайна/структуры сайта. Часто 2-й вариант попросту технически не реализуем из-за сложности дизайна или GUI. П.С. Семантически привязать лейблу к элементу можно, при необходимости, и с помощью WAI-aria, например.

на CSS: _http://jsfiddle.net/webviper/B9AMZ/16/ - делалось для других целей, но под меню подходит

В этом-то и странность... У меня углы не закругляются и в IE7 пункты меню выводятся друг под другом, как если бы фиксы не работали... Смотрю через IE9 в режимах 8/7. И градиент у меня не работает в этих браузерах. Просто желтый(#ffffb7) цвет при ховере П.С. Советую попытаться проверить сайт на нативном 8-м.

Проблемы видны только на нативном IE8? Я вижу только, что похоже не работают твои display-table.min.htc и PIE.htc... С hover все норм в режимах 8, 7

1. отсутствуют hover'ы 2. карандаш должен по макету налазить на пункт меню - "contacts"? 3. неверное применение тега <menu> - _http://forum.htmlbook.ru/index.php?showtopic=36592 4. не нашел заголовков <hN> 5. полное отсутствие семантики. Ссылки Категорий и Архивов сделаны не списками... 6. элементы поиска не в форме. ... П.С. Как для первой верстки - хорошо, ИМХО.

Возможно и ошибаюсь, сейчас тоже нету возможности просмотреть видио) Когда разберешься - отпишись в теме Занимался/экспериментировал этим вопросом очень давно и уже точно не помню нюансы) А сейчас не заморачиваюсь этим: рентабельность этого метода я заметил(тогда) только на страницах с большим количеством изображений. И в моих случаях размеры им все равно задает контент-менеджер)

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

"Скорость рендеринга страниц: исследования, замеры, автоматизация": _http://video.yandex.ua/users/ya-events/view/275/?cauthor=melik-alexey&cid=1 - доклад интересный, если еще не видел. И в нем упоминался данный вопрос. Насколько я знаю, не обязательно задавать размеры изображений именно через атрибуты, поскольку стили (обычно) загружаются(или берутся с кеша) до построения DOM дерева.

CSS не может влиять на DOM структуру/иерархию. Ты слишком много нафантазировал...)

Потому-что <img>, всегда(насколько я знаю) перекрывает внутреннюю тень родителя

canvas - не параметр, а объект. Никаких особых технологий/методологий тут не используется. Кроме, разве-что анимации с бегущим человечком... По-этому и некуда конкретно направлять. Это сплошной креатив, в том числе и сам код. Это тоже самое, что спросить у изобретателя - "как вы изобретаете все свои приборы?". Ну... молча...) Выше, я В общем-то описал эту самую "технологию") изучать событие scroll в js "HTML5" тут не причем. HTML5 == HTML)