SelenIT

Высота и ширина куска левой колонки, "врезающегося" в футер, известны (высота — 40px, я полагаю)? Если да — так вделать в футер прозрачную пустышку соотв. размера, с float:left, а левую колонку пустить поверх с помощью position:relative и z-index'а...

На всякий случай, неплохая ссылка по теме про странности списков в старых IE: http://cssing.org.ua/2008/03/09/ul-li-ie-bug/

+1 за отдельный добавочный tr для кнопок. С точки зрения табличной верстки — самое очевидно напрашивающееся решение. При динамическом выводе, да, придется слегка усложнить логику шаблона — но это решаемо.

10-й Оперы в Рунете осталось 4% (почти столько же, сколько IE6), за границей — вообще милликрохи процента. В актуальной 11-й всё отображается как надо. Имхо, можно не париться

Не совсем. Первые 127 байт/символов совпадают (латиница, цифры, базовая пунктуация и т.п.), вторые 128 у всех по-разному (причем ANSI существует в разных вариантах, для разных наборов символов). И в UTF-8 эти же первые 127 основных символов тоже обозначаются теми же самыми байтами, а все остальные символы - уже несколькими байтами на символ.

Не может такого быть, если браузер не совсем уж ископаемый. Раз появился перенос — значит, ширина заполнена, по стандарту так. В примере psywalkerа же такой ерунды не возникает (у меня по крайней мере), а значит, дело точно не в "выравнивании". Хорошо бы увидеть реальную проблемную страницу...

А он и есть файл в ANSI-кодировке (даже вообще в ASCII). По построению самого UTF-8

Почему неопределенность? Там вполне определенно сказано т.е. h1 в каждой секции не является обязательным требованием (хотя и дает некоторое преимущество легкости редактирования) и посему SEOшная традиция "один h1 на страницу" не идет фатально вразрез со спекой. Как я это понимаю...

Мое ламерское имхо я могу аргументировать пунктом 4.4.11 "живого стандарта" и примерами кода, приведенными там в качестве семантически эквивалентных. Хотя про вариант с h1 в каждой секции и сказано, что он "might be easier to maintain (e.g. if sections are often moved around in editing)". Но всего лишь might же, а не must какой-нибудь...

Вот здесь какие-то умные ребята вроде сделали: http://топэксперт.рф/ Всю методологию не раскрывают, но по их собственной трактовке влияние повторяющихся h1 можно считать незначимым (0-20% — фактор не влияет, про знак ничего не сказано). А в качестве "авторитетного мнения изнутри" можно ссылаться на комментарий Александра Садовского, руководителя веб-поиска Яндекса. Но вот лично на мое ламерское имхо... раз новой спеке по большому счету плевать на номер заголовка (важна лишь вложенность), а старые индексаторы пока во многом заточены под семантику HTML3-4, и вот такая мелочь, не противоречащая ничему новому, при удачной фазе луны может улучшить цвет лица у старого на целых 15% — почему бы и нет, черт возьми, надо ли идти грудью на принцип и возводить перфекционизм в квазирелигиозный абсолют (как и оппоненты, кстати, только в другую сторону)?

Насколько я понимаю, к тому моменту, когда доходит до интерпретации стилей, парсер разметки уже отработал (как умел) и перегнал разметку в железобетонную DOM-структуру. И стили могут на нее влиять лишь в своей ограниченной песочнице — в пределах document.deafultView в "стандартных" и element.currentStyle/runtimeStyle в "непарнокопытных", соотв-но . Что-то большее дозволено лишь скриптам...

Увы. Специфические DOM-свойства (типа checked, selectedIndex и value) стиль навесить бессилен, на ближайшее время это прерогатива парсера разметки...

В чем, если не секрет, смысл сего загадочного действия? Стандартисты согласны с этим лишь наполовину Как по мне, так в первых двух строках ну явно th-ки напрашиваются . Но у автора темы проблема еще в том, что таблица впихнута в жуткую квирковую страницу, с бухты-барахты поставить на нее нормальный доктайп он едва ли сможет. По-хорошему, да, ему надо бы переверстать всё "по феншую", но пока для начала надо хотя бы научиться считать ячейки в строках (с учетом colspan-ов) и убрать грубые ошибки структуры...

Вот так у меня получилось (после нескольких бесплодных попыток): body { behavior: url(test.htc); } /* в основном CSS-нике, путь относительно HTML! */ <?xml version="1.0" ?><!-- это файл test.htc --> <public:component xmlns:public="urn:HTMLComponent"> <script type="text/javascript">//<![CDATA[ var l = document.createElement('link'); l.href = "special.css"; // путь к отдельному CSS-нику для IE тоже относительно HTML! l.rel = "stylesheet"; l.type = "text/css"; previousSibling.appendChild(l); //]]></script> </public:component> Проверял в IE9 (включая все режимы-притворяки, включая квиркс) - работает везде. Честно говоря, не уверен, есть ли в этом выкрутасе практический смысл. Просто насчет \9 у меня были сомнения в связи с этим сообщением. А тут какая-никакая документированная фича. Но сейчас FF3.5 уже можно не учитывать, а в краткости записи и независимости от JS тоже есть неслабые плюсы...

Нет, такого не наблюдаю, иконки на месте. IE 9.0.8112.16421. Может кеш шалит?..

У меня вроде всё отображается, как в FF4...

Если поводом была моя ремарка здесь, то постараюсь внести ясность: речь шла исключительно о CSS-файлах, размер которых - с оптимизацией или без - как правило, составляет сущий децл в сравнении с содержанием современных страниц (всякими там видимороликами и т.п., чем нас так радует, в числе прочего, новый живой ХТМЛ), а с учетом кеширования миллисекунды выигрыша и вовсе будут заметны один раз при первой загрузке. И такие практики оптимизации, как, например, группировка свойств по значениям, а не элементам (когда в одном месте оказываются сгруппированы селекторы заголовка, активной ссылки в футере и подписи фотки только потому, что у них обший светло-оранжевый фон, зато правила, относящиеся к самому заголовку, приходится с лупой выискивать по всему файлу) на этапе разработки очень быстро начинают плодить путаницу и превращают работу в черт-те что. И да, лично я не вижу катастрофы в том, чтоб на странице с хитрым JQ-плагином CSS-ник, относящийся к этому плагину, подключался отдельно, а не пихался бездумно в основной (особенно если такая страница на всём сайте одна из тысячи). Важнее, действительно, оптимизировать картинки, особенно большие. Хотя, опять-таки, лично я нередко вначале делаю верстку на отдельных картинках, и лишь ближе к концу, когда мне уже абсолютно ясно, сколько картинок получается всего, каковы их окончательные размеры, как они группируются и т.п. - только тогда объединяю их в спрайты (а то, если с самого начала делать спрайтами, бывает, что какая-нибудь одна зараза выбивается на четыре-пять пикселей и вынуждает менять расстояние между кусками и, соответственно, переправлять все уже проставленные в CSS-нике background-position'ы...). Стремление к уменьшению нагрузки (по объему и числу запросов) я считаю в высшей степени похвальным, но оно не должно превращаться в навязчивость. По-моему, программистский подход "сперва сделай, чтоб работало, потом подправь, чтоб работало красиво, потом доработай напильником, чтоб работало быстро" достаточно универсален и здесь тоже применим. Конечно, с ростом профессионализма сначала первые два шага, а потом и третий с ними, постепенно сливаются в один. Но всё-таки, в аналогии со спортсменом - не умаляя роли ежедневных тренировок, лично я не вижу особого смысла отрабатывать особенные финты, нырки и кувырки, идя в гастроном за батоном или догоняя автобус на улице... Впрочем, спорить с профессионалами не берусь - я-то пока и на продвинутого любителя не тяну... На убогом экране трехлетнего ноута JPEG-разводы вокруг лица той модели режут глаз и в исходном варианте, но в уменьшенном, по-моему, вокруг губ они стали-таки позаметнее, плюс розовый блик на лбу обзавелся резкими краями и стал похож на какое-то болезненное пятно. Вообще довольно часто замечаю, что картинки, отлично выглядящие на хороших дизайнерских экранах, внезапно обнажают все недоработки как раз на дешевеньких офисных (вопреки интуитивному здравому смыслу).

Когда-то давно в не помню каких браузерах, вроде бы, Флеш с wmode=transparent так работал — прозрачные области были прозрачными и для кликов. Но полагаться на это я бы не рискнул, особенно теперь

В IE6 px не масштабировались (совсем), а поскольку некогда это было >60% юзеров, поневоле приходилось учитывать. Сейчас, имхо, большого смысла нет.

Как вариант — добавить behavior со скриптом, динамически подгружающим дополнительный CSS-файл?

Если уж на то пошло, то div тоже неуниверсален — его нельзя запихнуть, например, в абзац или address. Если уж постигать мощь абстрактного SGML, то с таким тегом, от которого у реальных парсеров нет вообще никаких ожиданий в плане дефолтного поведения. Т.е. таким, которого они просто не знают — напр., просто и без выкрутасов: <tag> Но на этом пути мне тоже упорно видится тот троллейбус из буханки, причем на двух колесах и с педальным приводом. Потому что на эту тему уже давно есть готовое решение, работающее во всех браузерах, включая IE5 (три буквы, первая X)

Какой браузер? Бывает, что браузеры в принципе не позволяют уменьшить текст меньше некоего предела "читаемости", иногда этот предел даже можно регулировать настройками (точно помню, что так вели себя какие-то Оперы внутри 9-й ветки, не удивлюсь, если поймаю на подобном Хромого). Попробуйте для минимального разрешения не уменьшать, а увеличить шрифт, если сработает — вероятно, дело в этом...

Буква X отвечает за синтаксис, Strict/Transtional — за набор допустимых тегов/атрибутов и наличие/отсутствие дополнительных требований к стуктуре (напр. обязательности блочных оберток внутри body и form). XHTML Transitional буквально означает — можно описывать почти любую расхлябанную структуру а-ля 90-е, зато по модному XML. Вроде как ехать на старой телеге, запряженной старой клячей, зато покрасить эту телегу самой современной краской и "обуть" в модную гоночную резину . Учитывая, что XML-ность такой разметки учитывается браузерами от силы в одном проценте случаев, применимость к "правде жизни" в нем, имхо, весьма условная. Так и есть, но это как раз правда жизни, и многострадальный "живой стандарт" это зафиксировал. После такой фразы ну просто просится эта картинка...

Я в шоке Правильность оформления по XML абсолютно никак не пересекается с делением Strict/Transitional/Whatever. За XML-правильность или ее отсутствие отвечает буква X в XHTML (и, соотв-но, ее отсутствие в HTML). Transitional отвечает за допустимость использования пережитков HTML 3.2 (вернее, всего того, что считалось такими пережитками в 2000-м — <u>, <font>, <a target="..."> и т.п.), неважно в каком синтаксисе. Еще Transitional-ы разрешают строчные теги прямо в body без оберток, Strict-ы запрещают (опять же в обоих синтаксисах). Поэтому XHTML 1.0 Transitional вообще самый бредовый диалект, который можно придумать — берем все старые пережитки и тянем их в прогрессивный (как нам кажется) синтаксис . HTML 4.01 Strict строже (по структуре и семантике). "Полустандартный" режим, в который браузеры валятся при Transitional-доктайпах, "лучше" полностью стандартного с точки зрения интуиции — некоторые вещи в нем ведут себя так, как этого ожидаешь, а не так, как положено по стандарту (пресловутые отступы под картинками в ячейках таблиц и еще несколько подобных мелочей). Поскольку старые браузеры (упомянутый IE7) по стандарту вообще не умели, поведение "полустандартного" режима кажется более кроссбраузерным — глючат все, но более-менее похожим образом . Но человеку, привыкшему к стандартному поведению, такая "телепатия" лишь мешает. За пример, когда от разницы Strict/Transitional меняется поведение IE7 (или более старых IE), я по-прежнему готов заплатить сотку баксов (конечно, не считая тривиальных случаев отсутствия ссылки на DTD или xml-пролога в IE6, выливающихся в банальный квирксмод). По-моему, это из той же серии, что инопланетяне, которых каждый видел (или, как минимум, знает человека, кто видел), но никто не может предоставить хоть одно фактическое доказательство...

На самом деле дивы нужны довольно редко. Потребность в нескончаемых дивах обычно возникает от непонимания предметной области или незнания CSS . В HTML масса "естественных" блочных контейнеров (form, fieldset, blockquite и т.д.), вполне способных нести на себе оформление "по совместительству". Во многом CSSщики этим исправляют ошибки молодости. Сделали бы CSS1 не таким противоинтуитивным, "лишь бы назло MS", узаконили бы сразу боксовую модель border-box (на момент принятия стандарта реализованную во всех браузерах!) и наследование фактической высоты предка - глядишь, не было бы такой частой потребности в вычислениях... Потому что при Transitional новые хорошие браузеры вынуждены (отчасти) "косить" под старые глючные. Порой ценой отказа от хороших новых фич. На мой взгляд, это путь... может и не в никуда, но уж точно не в светлое будущее P.S. А вообще годный флейм получился, как всегда из подобных тем, вы не находите?