SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
При написании кода броузер перестал понимать блокнот
SelenIT replied to luxeon's question in HTML Coding
Про кодировку я имел в виду другое: при сохранении файла в блокноте внизу соотв. окна есть выпадающий список "Encoding". Если там выбрать UTF-8, блокнот вставляет в начало файла особую метку в 3 байта размером, иногда она может влиять на что-то. И еще, с таким доктайпом страницы рисуются в Quirks mode, в котором браузер имитирует глюки IE5 (напр., та же точка отсчета при позиционировании) и игнорирует стандарты. Еще есть смысл проверить настройки безопасности (в тяжелых случаях IE блокирует любые файлы с локального диска, даже просто стили без экспрешнов), а еще лучше — поставить локальный HTTP-сервер (напр., "Денвер") и тестировать через него... -
При написании кода броузер перестал понимать блокнот
SelenIT replied to luxeon's question in HTML Coding
1) В какой кодировке проблемные файлы? 2) Какой доктайп на проблемных страницах? Можно поподробнее? -
Имхо, это из общей логики вытекает. Браузер смотрит, какие стили ему доступны, и применяет их в порядке "живой очереди": встретил новое правило для знакомого селектора — прежнее забыл. Просто в варианте с условными комментами IE видит два источника стилей (общий для всех и "свой личный"), а другие браузеры — лишь один...
-
Гайдамак, может быть, это поможет? Рядом с этим дивом в коде случайно комментарии не затесались?
-
Для разовых задач — есть масса онлайновых сервисов для этого дела (навскидку первый попавшийся).
-
Кроме вложенности, здесь еще работает специфичность. У селектора по ID она выше, чем у селекторов по тегам и классу. Придется, видимо, дописать этот ID: #content table.table_price td, th {...}
-
Div внутри таблицы меняет ширину столбца, а не должен...
SelenIT replied to Aurica's question in HTML Coding
table-layout:fixed не помогает? -
Список рекомендованных консорциумом доктайпов есть здесь: http://www.w3.org/QA/2002/04/valid-dtd-list.html Хотя для 98% практических задач, имхо, лучше всего подходит простой, кроссбраузерный и future-proof'нутый <!DOCTYPE html>
-
На самом деле (т.е. по стандартам) с точностью до наоборот
-
Имхо, лучше и то, и другое указывать только для IE6 – все-таки тут CSS-свойства используются не по назначению, а ради побочных эффектов, так что это хак. Но проблем от about:blank в качестве адреса картинки лично я нигде не наблюдал.
-
Уточнение: не table, а table-cell. А для IE (ниже актуального 8-го)... да, или вышеупомянутый способ с доп. контейнером и top: -50%, либо экспрешн (подробнее). В таблицах и "как бы таблицах" - не только.
-
Дело даже не в самом формате PNG, а в "непонятках" между ним и IE. Формат-то сам по себе хороший. Просто у него слишком много фич и разновидностей, в которых немудрено запутаться (см. напр. http://www.artlebedev.ru/tools/technogrette/img/png-4/). Многие проблемы от старых инструментов (напр. Фотошопа ниже CS3), с новыми правильными инструментами (напр., Fireworks) проблем должно быть меньше.
-
Поддерживаю BassEastа, с value работать как-то надежнее.
-
Чем не подходит стандартный <acronym title="Frequently Asked Questions">FAQ</acronym>?
-
Интуиция подсказывает, что проблема может крыться в метаинформации про гамму картинки, можно попытаться зачистить ее старинной утилиткой TweakPNG (chunk gAMA). Но вообще непростые взаимоотношения IE и PNG — это отдельная мыльная опера… может, проще пересохранить картинку в другом формате?..
-
<telepat>А слова между "палками" — не ссылки случайно? Тогда им, по идее, можно padding-и задать…</telepat>
-
Гугл не так давно научился индексировать, но обычно получается ужас (ряды бессмысленных цифр и т.п.). А вообще есть варианты и без флеша (один как минимум, но на моей старой машине (Duron-1200, 512M) тормозит немилосердно. И вообще, имхо, подобная "красота" сводит на нет всю логику привычного облака — наглядное отображение популярности тегов в их размере...
-
Получается без лишнего запроса. Кроссбраузерность в данном случае не нужна, т.к. это фикс только для IE6, в других браузерах position:fixed работает без таких извр... пардон, ухищрений
-
1) = - присваивание, сравнение - == (часто советуют писать константу слева, а переменную справа, тогда ошибку нельзя не заметить). 2) document.write не работает после загрузки документа. Для отладки вполне годится alert(). 3) break не нужен.
-
У самых новых фоксов (по-моему, в ветке 3.1 → 3.5, которая должна выйти где-то через месяц, если не раньше) вроде бы эту проблему пофиксили. А вообще на то экспериментальная поддержка (-moz-, -webkit- и пр.) и экспериментальная...
-
Justnewone, там, наверное, была жесткая "заточка" под определенный виндовый шрифт, возможно, какой-нибудь компактный типа Arial Narrow. Поэтому не все, что должно было быть в одну строчку, в нее уместилось. По идее, если следовать правилу "верстка должна выдерживать 2 шага увеличения/уменьшения при чисто текстовом зуме а-ля FF2", такой проблемы возникать не должно...
-
Не совсем так. IE отображает таблицу целиком, когда уже хватает данных, чтобы определить размеры каждой ячейки, чтоб не перерисовывать уже выведенный контент по нескольку раз. FF отображает ячейки по мере загрузки, как если бы очередная загруженная ячейка была последней в таблице, поэтому ход загрузки виден более наглядно, но в ее процессе ячейки постоянно перестраиваются, ужимаются и визуально "прыгают" с места на место. Кстати, IE, насколько я помню, тоже умеет выводить таблицы по мере загрузки — если зафиксировать ширину всех ячеек и задать таблице table-layout:fixed (ну и доктайп стандартный, само собой).
-
Имхо, пункты, сантиметры и т.п. хороши для печати, на экране они особого смысла не имеют (к тому же их интерпретация на экране может зависеть от ОС и ее настроек — по крайней мере, так было раньше). Основное противопоказание пикселей — IE6, во всем остальном их хоть как-то можно отмасштабировать (лично я старомоден и предпочитаю масштабировать только текст, если можно — но я нынче в меньшинстве). Противопоказание em-ов — если у юзера шрифт увеличен по дефолту, то в FF он увидит сайт с немного другими пропорциями текста к графике, чем задумывал дизайнер (имхо, это пустяк, правильный дизайн не должен от этого страдать... но тем не менее). Плюс браузеры часто округляют дробные em-ы по-разному (IE, например, обрезает до двух цифр после точки). А вот в чем прикол ставить базовый размер в пикселях и от него плясать в em-ах, честно говоря, я не совсем понимаю. Просто в качестве а-ля "именованной константы" вместо конкретных чисел? Но пиксельная точность ведь все равно из-за округления наверняка потеряется. Разве что если этот базовый размер предполагается менять яваскриптом — тогда смысл есть, но нужны ли такие сложности...
-
Потому что HTML - не XML. И браузеры рендерят не код, а DOM. В которой в P физически не может быть вложен другой P или любой другой блочный элемент, поэтому открывающий тег любого из них автоматически закрывает предыдущий абзац. Рекомендую при отладке смотреть именно на DOM (с помощью Firebug, Dragonfly, IE8 Developer Tools и т.п.).
-
В IE6, о котором речь - разницы никакой. Проблема именно в том, что document.body.scrollTop работает только в режиме совместимости, а нужен document.documentElement.scrollTop. Кстати, вместо url('faux-image.png') неплохо справляется url(about:blank).