rash

+1, даже если сейчас кажется, что это ничего страшного...

А для IE 6, возможно, придется эту картинку прятать и использовать AlphaImageLoader с sizingMethod='scale' Она по высоте может на 100% иначе не тянуться.

На тяжелых страницах (с нагруженным DOM'ом) глобальный сброс может ощутимо замедлить рендеринг. На средних и небольших страницах никто ничего не заметит.

У него ужасающе непродуманный интерфейс. Для отладчика - сойдет, а как постоянный браузер он хорош только по сравнению с IE. Боюсь, грядет очередной холивар :-) Была уже подобная тема, можно там продолжить...

И все-таки от глобального сброса на "тяжелых" страницах лучше отказаться.

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

Я знаю, но ходить по улице с какими-нибудь огромными наушниками мне неудобно.

Да, насчет этого жаль, конечно, но блин управление на шнуре - конфетка такая... хочу -)

Неверно. Сайт - лицо фирмы.

Запись короче :-)

Ну вы бы условия описали поподробнее, все было бы намного проще. Но хорошо, что вы сами нашли решение.

просто a img {border: 0;}

Не обязательно, но крайне полезно.

У меня нано - нравится, но у меня старый, второго поколения, он еще узкий по форме. Не понимаю, как сенсорная панель может раздражать - она как раз создает ощущение аналогового управления, а ничего приятнее аналогового управления быть не может. iPod video классно лежит в руке или кармане, но тяжеловат. Шаффл старый (на прищепке и с колесиком) мне нравится, а новый видеть не приходилось. Конечно, специальные наушники - это минус, но у моего нано второй год работают "родные". А с управлением на шнуре вообще, полагаю, должно быть очень удобно.

У элемента фиксированная ширина?

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

Вы каким редактором пользуетесь для редактирования этого кода?

Неверно. И UTF-8, и UTF-16 и UTF-32 могут представлять любой из набора символов UNICODE. Разница только в способе представления. В настоящее время UTF-8 позволяет представить 2097152 символов, то есть все символы, определенные в юникоде. В перспективе возможно представление до 281474976710656 символов, хотя это пока не планируется.

Она удобнее тем, что может включать любые существующие символы, в то время, как набор символов в windows-1251 ограничен. Некоторых смущает то, что символы, не входящие в ASCII кодируются больше, чем одним байтом, но я считаю, что чем беспокоиться о байтах в исходном тексте, лучше графику оптимизировать как следует.

В задаче был ролловер. Ролловер подразумевает два элемента. Если элементов может быть больше, то это не ролловер, и задача сформулирована неверно.

Ну вот только для IE6 его и написать -)

Приблизительно это я и имел в виду, просто не с таким максимализмом :-)

Byte Order Mark - специальный символ в самом начале текста, который позволяет определить, в каком порядке идут байты в символах, закодированных в UTF-16, так как здесь возможны два варианта. Для UTF-8 этот символ не имеет смысла, но иногда используется просто чтобы показать, что текст сохранен в юникоде. Использовать BOM при сохранении текста для веба нельзя - это является причиной многих проблем.

Любая универсальная методика / технология / подход / инструмент делают многое, но все - одинаково плохо.

Я знаю, это была шутка, если кто не понял :-) Использовать стили, если это позволит обойтись без JS, хорошо уже хотя бы потому, что все будет работать даже без JS.