Ирония? :)
Таблицей нельзя. Не из-за того, что я такой упертый принципиальный осел, начитавшийся, что «div-ы это круто».
Первоначально дествительно все было на таблицах, и проблем было значительно меньше, кроме ключевой — тормозило это дело страшно. Вложенность получалась такая, в ie страница загружалась 6-7 секунд. Это на локальной машине, без скриптов. Контент не будет показан, пока не будет загружена вся таблица целиком. Таблица не верхнем уровне иерархии в сложном макете вызывала недопустимую медлительность отрисовки.
Поэтому все (без фанатизма) переделывается на divах
Этот пример — типичная конструкция, которую в жизни приходится многократно вкладывать друг в друга. Обвешанную дополнительными стилями, во взаимодействии с соседями… Конкретно эту форму можно сделать таблицей, но это не решит общую проблему
Спасибо за совет по существу. К сожалению, нет, не помогло.
Чтобы баг воспроизводился необходимо, чтобы кодировка html файла соответствовала тому, что указано у него в head. Я тестировал в utf-8 и windows-1251 — одинаково.
Я прекрасно понимаю, что quirks — это плохо.
Но еще хуже слепо следовать правилам или догмам вроде «верстайте все и всегда в strict и будет счастье». Для меня главное — это решить поставленную задачу наиболее эффективным способом. Немного нижу я написал, почему именно quirks для ie — в противном случае общая задача, которая стоит передо мной, решается не эффективно.
Ваш трехлетний опыт, видимо, пока еще не дал возможности осознать, что html и css — это не только верстка макетов страничек для интернета, где всегда просто взять и изменить. У нас вот, например, на этих технологиях строится интерфейс настольного приложения — сложного комплекного продукта, где все завязано одно на другое. И из-за мелкой проблемы нельзя вносить столь радикальные изменения, как переключение режима рендеринга.
С дикарями надо разговаривать на их языке — другой они не поймут. С глючным ie6 приходится работать соответственно
Возвращаясь к сути топика — вопрос был не про выбор режима рендеринга, а про специфический баг в выбранном режиме и можно ли с этим что-то сделать.
Да, совет хороший :)
Но я же не от хорошей жизни так делаю :)
Специфика дизайна такова, что для верстки требуется повсеместное использование конструкций стопроцентной ширины или высоты с отступами. В режиме соответствия стандартам, насколько я знаю, это делается двумя способами:
а) через два дива, одному отступы, второму ширину
на сложном макете дивов получается столько, что это приводит к тормозам при отрисовке страницы в браузере.
И не кошерно это — вводить лишние структурные элементы из-за чисто оформительских требований. И есть еще одна проблема, связанная с этим, но это уже слишком глубоко копать надо
б) с использованием css свойства border-box. IE это свойство благополучно не знает, так что поэтому для него и выбран режим quirks, в котором он рассчитывает ширину так же, как нормальные браузеры при использовании border-box
Со всеми вытекающими негативными последствиями этого режима. Собственно, одно из странных проявлений я и описал в топике, надеясь, что кто-то сталкивался с подобным и может посоветовать что-то кроме «делайте в strict — и будет вам счастье»
Мой стаж существенно больше вашего, и тем не менее могу сказать, что это далеко не всегда так категорично, как вы утверждаете. При тех ограничениях, которые я себе ставлю (безтабличная верстка, без применения js, масштабируемый размер шрифта, разные разрешения экрана, одинаковость отображения в браузерах). При упрощениях, конечно, да.
Речь идет не об обычном макете сайта, а сложном интерфейсе декстопного приложения, который сделан на html+css. Помимо сложности структуры есть еще ряд требований по отделяемости, независимости и переносимости кусков, из взаимосвязи и т.д.
Тот макет, с которым я работаю, с доктайпом без проблем верстать можно было бы, если бы ie понимал некоторые современные css-свойства вроде border-box.
Сами понимаете, от специфики конкретной ситуации сильно зависит. В моей конкретно ситуации невозможность использования border-box ведет ко значительному увеличению количества лишних структурных элементов, появлению моря оформительских div-ов
С радостью бы отказался, но это необходимое условие. Основной макет достаточно сложный и добиться всей нужной функциональности и «укрощения» ie удалось именно в quirks mode для него. Остальные браузеры работают в strict-e
Дело не только в призязке к местности, а еще и в общей аккуратности, опрятности, чистоте линий и легкости восприятия рисунка. Это мало кому удается так, как удалось автору второй карты.
Вторая схема очень хорошая. Очень-очень хорошая, скорее, даже не схема, а рисунок, живой и естественный, в отличие от роботизированных схем, которые больше подходят для восприятия машиной, а не человеком.
Из незначительных недостатков — отсутствие обозначения железнодорожных станций
Спасибо за идею
Таблицей нельзя. Не из-за того, что я такой упертый принципиальный осел, начитавшийся, что «div-ы это круто».
Первоначально дествительно все было на таблицах, и проблем было значительно меньше, кроме ключевой — тормозило это дело страшно. Вложенность получалась такая, в ie страница загружалась 6-7 секунд. Это на локальной машине, без скриптов. Контент не будет показан, пока не будет загружена вся таблица целиком. Таблица не верхнем уровне иерархии в сложном макете вызывала недопустимую медлительность отрисовки.
Поэтому все (без фанатизма) переделывается на divах
Этот пример — типичная конструкция, которую в жизни приходится многократно вкладывать друг в друга. Обвешанную дополнительными стилями, во взаимодействии с соседями… Конкретно эту форму можно сделать таблицей, но это не решит общую проблему
Чтобы баг воспроизводился необходимо, чтобы кодировка html файла соответствовала тому, что указано у него в head. Я тестировал в utf-8 и windows-1251 — одинаково.
Я прекрасно понимаю, что quirks — это плохо.
Но еще хуже слепо следовать правилам или догмам вроде «верстайте все и всегда в strict и будет счастье». Для меня главное — это решить поставленную задачу наиболее эффективным способом. Немного нижу я написал, почему именно quirks для ie — в противном случае общая задача, которая стоит передо мной, решается не эффективно.
Ваш трехлетний опыт, видимо, пока еще не дал возможности осознать, что html и css — это не только верстка макетов страничек для интернета, где всегда просто взять и изменить. У нас вот, например, на этих технологиях строится интерфейс настольного приложения — сложного комплекного продукта, где все завязано одно на другое. И из-за мелкой проблемы нельзя вносить столь радикальные изменения, как переключение режима рендеринга.
С дикарями надо разговаривать на их языке — другой они не поймут. С глючным ie6 приходится работать соответственно
Возвращаясь к сути топика — вопрос был не про выбор режима рендеринга, а про специфический баг в выбранном режиме и можно ли с этим что-то сделать.
Но я же не от хорошей жизни так делаю :)
Специфика дизайна такова, что для верстки требуется повсеместное использование конструкций стопроцентной ширины или высоты с отступами. В режиме соответствия стандартам, насколько я знаю, это делается двумя способами:
а) через два дива, одному отступы, второму ширину
на сложном макете дивов получается столько, что это приводит к тормозам при отрисовке страницы в браузере.
И не кошерно это — вводить лишние структурные элементы из-за чисто оформительских требований. И есть еще одна проблема, связанная с этим, но это уже слишком глубоко копать надо
б) с использованием css свойства border-box. IE это свойство благополучно не знает, так что поэтому для него и выбран режим quirks, в котором он рассчитывает ширину так же, как нормальные браузеры при использовании border-box
Со всеми вытекающими негативными последствиями этого режима. Собственно, одно из странных проявлений я и описал в топике, надеясь, что кто-то сталкивался с подобным и может посоветовать что-то кроме «делайте в strict — и будет вам счастье»
Речь идет не об обычном макете сайта, а сложном интерфейсе декстопного приложения, который сделан на html+css. Помимо сложности структуры есть еще ряд требований по отделяемости, независимости и переносимости кусков, из взаимосвязи и т.д.
Сами понимаете, от специфики конкретной ситуации сильно зависит. В моей конкретно ситуации невозможность использования border-box ведет ко значительному увеличению количества лишних структурных элементов, появлению моря оформительских div-ов
Из незначительных недостатков — отсутствие обозначения железнодорожных станций
Новая иконка неплохая, разве что, на мой вкус, чрезмерно насыщенные цвета. И смотрится она, действительно «весьма гармонично», но не идеально родной