Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 106
We''re sorry, but we were unable to locate the attachment you requested.
Неплохая реализация, сейчас попробую!
Очень красивое решение. Жалко, что не до конца реализовано поведение блока, если выставить .fixedwidth в auto. Бета все-таки. Хотя, скрипт февральский, а это дает надежду на появление более свежих версий уже в скором времени. В реальных проектах я этот способ использовать, скорее всего, не буду (если только куски скрипта выдирать), но идея достойная уважения.
за решение спасибо
а за это - отдельный респект))
Работает во всех современных баузерах и IE6+
а за это - отдельный респект))
За это не мне, а Дэну Эдвардсу. :)
Я всего лишь рискнул доверившись его коду чтобы отказаться от хаков. Пока меня такой вариант устраивает — хаков для IE в других местах теперь требуется значительно меньше.
Я всего лишь рискнул доверившись его коду чтобы отказаться от хаков. Пока меня такой вариант устраивает — хаков для IE в других местах теперь требуется значительно меньше.
Очень полезная и интерестная реализация, добавил в избранное!
Мне понравилось...
отлично.
Имхо, лучший способ из всех приводимых здесь. Простой, надёжный, элегантный. Спасибо.
С векторными уголками это работает? (сорри, сейчас просто нет возможности самому проверить.)
Если вам известен способ сделать векторное изображение фоном, поделитесь пожалуйста.
Это совершенно другой способ скругления и как вы можете сами оценить — там не используется фоновое размещение векторной графики.
там не используется фоновое размещение векторной графики
Вы не правы. Там не используется загрузка внешнего файла-вектора.
Вы извините конечно, но перед тем как писать "вы не правы" разберитесь в ситуации. Мой способ подразумевает использование фонового отображения спрайта. Ваш способ не использует фоновый вектор (это факт в котором вы можете убедиться заглянув в код). Стало быть пока вы не покажете другой метод отображения векторной графики в качестве фона мой метод будет оставаться непригодным для реализации векторных скруглений. Именно об этом вы и спрашивали.
Хм.. Во-первых я не очем не спрашивал. Во-вторых я разобрался в коде, на который дал ссылку. В-третих я сказал, что вы не правы, т. к. вы утверждаете, что "там не используется фоновое размещение векторной графики", хотя именно это там используется. Используется, прописанием кода непосредственно в HTML, а не через подгрузку внешнего файла.
1. Ваш вопрос остался в комментарии. Странно, что вы об этом забыли.
2. Вы похоже совершенно не поняли кода, который привели. Это не фон.
3. Похоже нам с вами друг друга не понять. Предлагаю прекратить эту дискуссию.
2. Вы похоже совершенно не поняли кода, который привели. Это не фон.
3. Похоже нам с вами друг друга не понять. Предлагаю прекратить эту дискуссию.
Согласен закрыть дискуссию, только смотрите повнимательнее на имена, я в этом топике не задал ни одного вопроса.
Прошу прощения, действительно спутал вас с 
cryonyx
cryonyx
есть ограничения по использованию:
случай 1: поставьте высоту фиксированную, например 200px и уголки оказываются не на месте. Т.е. элементу нельзя задать фиксированную высоту - помещаю внутрь еще один див с фиксированной высотой, убираю фиксированную высоту из внешнего - картинка налаживается.
случай 2й: не работает в quirk моде. Пропишите в IE комментарии перед DOCTYPE чтобы перевести его в quirk режим (эквивалентный box-sizing:border-box в остальных нормальных браузерах) - не работает. Уголки не на месте.
случай 1: поставьте высоту фиксированную, например 200px и уголки оказываются не на месте. Т.е. элементу нельзя задать фиксированную высоту - помещаю внутрь еще один див с фиксированной высотой, убираю фиксированную высоту из внешнего - картинка налаживается.
случай 2й: не работает в quirk моде. Пропишите в IE комментарии перед DOCTYPE чтобы перевести его в quirk режим (эквивалентный box-sizing:border-box в остальных нормальных браузерах) - не работает. Уголки не на месте.
1. спасибо за замечание, подумаю можно ли это исправить без необходимости добавлять лишний тег.
2. в Quirks mode не пишу уже давно и другим не советую. "Стандартный" режим для того и предназначен, чтобы включать какую-никакую совместимость с современными стандартами.
2. в Quirks mode не пишу уже давно и другим не советую. "Стандартный" режим для того и предназначен, чтобы включать какую-никакую совместимость с современными стандартами.
по 2му пункту не соглашусь, так как не круглые уголки задают основные требования. Некоторые фреймворки работают только в border-box/quirk моде. И я думаю что любое грамотное решение должно работать в любом режиме. А то у вас появляется требование - только стандартный режим, хоть оно и не было озвучено.
Кроме того некоторые вообще голову не греют какой такой quirk-шмирк. Дело в том, что если DOCTYPE не указать, а начать сразу с < html> то страница будет в quirk моде.
есть ограничения по использованию:
случай 1: поставьте высоту фиксированную, например 200px и уголки оказываются не на месте. Т.е. элементу нельзя задать фиксированную высоту - помещаю внутрь еще один див с фиксированной высотой, убираю фиксированную высоту из внешнего - картинка налаживается.
случай 2й: не работает в quirk моде. Пропишите в IE комментарии перед DOCTYPE чтобы перевести его в quirk режим (эквивалентный box-sizing:border-box в остальных нормальных браузерах) - не работает. Уголки не на месте.
Так что о надежности можно говорить только для конкретных случаев.
случай 1: поставьте высоту фиксированную, например 200px и уголки оказываются не на месте. Т.е. элементу нельзя задать фиксированную высоту - помещаю внутрь еще один див с фиксированной высотой, убираю фиксированную высоту из внешнего - картинка налаживается.
случай 2й: не работает в quirk моде. Пропишите в IE комментарии перед DOCTYPE чтобы перевести его в quirk режим (эквивалентный box-sizing:border-box в остальных нормальных браузерах) - не работает. Уголки не на месте.
Так что о надежности можно говорить только для конкретных случаев.
сорри за двойной пост - сайт глючит.
Не совсем корректно выразился - комментарии прописать конечно в html файл < !-- — >, а не в IE. Кто в теме что такое box-sizing и с чем его едят, те поняли.
Не совсем корректно выразился - комментарии прописать конечно в html файл < !-- — >, а не в IE. Кто в теме что такое box-sizing и с чем его едят, те поняли.
Наверно я не достаточно в теме, раз ничего не понял про комментарии. :)
А можно для меня как-то попроще?
А можно для меня как-то попроще?
А если сделать в гифе прозрачный фон — уголки будут прозрачными? Если да, то вышлите немного песка из-под ног Дена Эдвардса — мне придется его целовать.
А в гифе уже прозрачный фон. Только в той части, которая отвечает за фон скругляемого блока. Если прозрачность переставить на часть, которая соответствует фону окружения, то ничего не получится — в этом месте будет просвечивать фон блока. Ден Эдвардс в данном случае помог отказаться от хаков для отображения этого стандартного кода в IE6+.
В гифе и так прозрачный фон, только на месте DIVа с информацией - на внутренних углах картинок.
Сейчас, погодите, набегут приверженцы "браузеровБезЯваскриптаВедьЭтоТакУдобноИБезопасно" и в пух и прах разорвут такую классную идею :)
Спасибо за топик.
Спасибо за топик.
один из самых лучших способов
Способ называется «IE, ты не умеешь CSS3? Тогда вот тебе 90 килобайт кода, сдохни!»
Мертворожденное решение.
Мертворожденное решение.
Ну если не перегибать так сильно палку, то да :)
Справедливости ради — и не 90 и не CSS3 и IE6 реально должен сдохнуть.
А насчёт мертворожденности не надо. Поживём — увидим. Не зря же ваша контора в каждом рекламном блоке продвигает FF3 и не только в своём.
Справедливости ради — и не 90 и не CSS3 и IE6 реально должен сдохнуть.
А насчёт мертворожденности не надо. Поживём — увидим. Не зря же ваша контора в каждом рекламном блоке продвигает FF3 и не только в своём.
А причём тут FF3? Речь шла о том, что подобные скрипты неприменимы в реальной практике. Побаловаться — да, а вот грузить 90 килобайт, заставлять и так шаткий IE6 всё это переваривать — это глупость.
Во первых не 90, а 38. Во вторых на старые автомобили есть налог — если нравится ездить на горбатом запорожце — плати и катайся. Не вижу проблемы в том, чтобы пользователи которые не хотят пользоваться современными браузерами для просмотра современных сайтов платили эти 38кб за такую возможность. Я понимаю, что политика вашей компании не предполагает разбрасываться посетителями, но для более мелких проектов такой выход вполне приемлем. И когда в следующий раз будете называть это глупостью вспомните как много всяких банковских сайтов до сих пор работают только в IE из-за его несовместимости со стандартами.
Ну, вы в коде дали ссылку на несжатую версию, которая весит 90 килобайт.
А так — да, 38 — чуть легче.
Я сейчас на Хабре пишу не как представитель моей компании, если что ) Так что оставим эти разговоры.
> вспомните как много всяких банковских сайтов
> до сих пор работают только в IE из-за
> его несовместимости со стандартами.
Вы поняли, что сказали? ) Банковские сайты работают только в IE по двум причинам:
— Секьюрность, основанная на ActiveX
— Специфика банковской системы, куда допускаются только проверенные (читай — устаревшие) разработчики сайтов.
Веб-стандарты не имеют вообще никакого отношения к подобному явлению.
…в общем, подобные вещи должны работать софтверно. Мне слегка лениво проводить тестирование насколько IE6 будет вешаться от подобных манипуляций со, скажем, 30-ю блоками со скруглёнными уголками на странице. Но я думаю, что можно себе это представить. Делаем вывод — это игрушка.
Если нет — то покажите хотя бы один серьёзный сайт, использующий IE7.js…
А так — да, 38 — чуть легче.
Я сейчас на Хабре пишу не как представитель моей компании, если что ) Так что оставим эти разговоры.
> вспомните как много всяких банковских сайтов
> до сих пор работают только в IE из-за
> его несовместимости со стандартами.
Вы поняли, что сказали? ) Банковские сайты работают только в IE по двум причинам:
— Секьюрность, основанная на ActiveX
— Специфика банковской системы, куда допускаются только проверенные (читай — устаревшие) разработчики сайтов.
Веб-стандарты не имеют вообще никакого отношения к подобному явлению.
…в общем, подобные вещи должны работать софтверно. Мне слегка лениво проводить тестирование насколько IE6 будет вешаться от подобных манипуляций со, скажем, 30-ю блоками со скруглёнными уголками на странице. Но я думаю, что можно себе это представить. Делаем вывод — это игрушка.
Если нет — то покажите хотя бы один серьёзный сайт, использующий IE7.js…
Ну, вы в коде дали ссылку на несжатую версию
Спасибо, что заметили. Уже поправил.
А так — да, 38 — чуть легче.
На практике соизмеримо со средней картинкой. Даже логотипы у некоторых бывают тяжелее.
Банковские сайты работают только в IE по двум причинам:
— Секьюрность, основанная на ActiveX
— Специфика банковской системы, куда допускаются только проверенные (читай — устаревшие) разработчики сайтов.
Некоторые банковские сайты работают только с IE и какова бы не была в том причина, я как пользователь Linux вынужден ухищряться значительно сильнее, чем просто загрузить лишние 38кб для того, чтобы иметь возможность посмотреть остаток на счёте. И это можно назвать глупостью не в меньшей степени, чем небольшой патч, который делает IE совместимым с качественным кодом.
…в общем, подобные вещи должны работать софтверно. Мне слегка лениво проводить тестирование насколько IE6 будет вешаться от подобных манипуляций.... Но я думаю, что можно себе это представить. Делаем вывод — это игрушка.
Слишком поспешный вывод. Явный подгон задачи под ответ. Наверно сказывается усталость. Я только что повторил тестовый блок в файле 100 раз и никакого замедления работы IE6 не заметил.
покажите хотя бы один серьёзный сайт, использующий IE7.js
Увы. Однако это не только не значит, что их нет, но и не мешает мелким сайтам использовать такой шанс.
я как пользователь Linux вынужден ухищряться значительно сильнее, чем просто загрузить лишние 38кб для того, чтобы иметь возможность посмотреть остаток на счёте
Объясните мне, пожалуйста, какое отношение имеют CSS3-свойства к тому, что банковские сайты не работают в Linux'е? Я, честно говоря, в растерянности.
Сделаю ещё одно поспешное заявление: ни одна серьёзная контора сегодня не может себе позволить сайта, который не работает в IE6.
Во первых не CSS3, а CSS2. А во вторых вы провели аналогию не в том направлении. Главная ошибка вашего последнего утверждения в том, что вы почему-то решили, что я ратую за отказ от поддержки IE6. Тогда как библиотека Эдвардса наоборот позволяет IE6 лучше (хоть и не идеально) работать с кодом написанным по стандарту. И когда я говорю про тех разработчиков, которые пожертвовали поддержкой всех браузеров кроме IE я также имею в виду, что они вряд ли отказались от максимальной совместимости, если бы такая была в их распоряжении. Они пошли по пути наименьшего сопротивления отлаживая код только в IE, а 37signals пошли по этому пути отказавшись от IE6. И библиотека Эдвардса это шаг на пути к объединению и единообразию. Так более понятно?
Можно я тут тоже приткнусь? Дело в том, что я какое-то время назад пробовал сверстать пару макетов с использованием IE7.js и пришел к выводу, что использование этой библиотеки в рабочем проекте ничего хорошего не несет - макеты сложные и проявляются новые непонятные и неизведанные глюки, которые уже не правятся привычными дедовскими способами.
Там где раньше хотелось задать zoom:1 или position:relative - видимые артефакты уже не исчезают.
Да попробуйте просто взять сложный и сверстанный по стандартам макет с отдельной таблицей стилей для IE, убрать ее и применить библиотеку, а потом полечить проявившиеся артефакты. Уверяю, будет занимательно.
Там где раньше хотелось задать zoom:1 или position:relative - видимые артефакты уже не исчезают.
Да попробуйте просто взять сложный и сверстанный по стандартам макет с отдельной таблицей стилей для IE, убрать ее и применить библиотеку, а потом полечить проявившиеся артефакты. Уверяю, будет занимательно.
Ну вот, суровое и здравое мнение.
На Вебмасконе сейчас один товарищ тоже жалуется — применил к сайту superUltimatePNGfix.js и всё поехало в IE… Ещё бы ) автор библиотеки не видел вашей вёрстки и не предупредил, что вставит парочку блочков, из-за которых всё сломается.
Вот и я говорю — все эти библиотеки разрабатываются в стерильных условиях и никогда не смогут быть защищены от багов. Работать с багами IE мы уже привыкли (опыт, как-никак) то изучать баги IE8.js — дело пустое.
На Вебмасконе сейчас один товарищ тоже жалуется — применил к сайту superUltimatePNGfix.js и всё поехало в IE… Ещё бы ) автор библиотеки не видел вашей вёрстки и не предупредил, что вставит парочку блочков, из-за которых всё сломается.
Вот и я говорю — все эти библиотеки разрабатываются в стерильных условиях и никогда не смогут быть защищены от багов. Работать с багами IE мы уже привыкли (опыт, как-никак) то изучать баги IE8.js — дело пустое.
При всём уважении вы снова передёргиваете. И про "стерильные условия" и про "все эти библиотеки". На самом деле беспредметно и голословно. Я никогда не утверждал, что эта библиотека или какая-то другая является панацеей (раз уж Microsoft не могут выпустить полноценного патча, то много ли можно сделать через js?) Однако в некоторых случаях, как описанный здесь, эта библиотека де факто является полезной.
Ладно, закопались в беспредметных рассуждениях.
Резюмирую.
Я не готов отдавать свою вёрстку на растерзание скриптам, которые:
— Исправляют даже те особенности IE, которыми я могу не пользоваться в отдельном проекте
— Загружают память IE довольно большим массивом данных, что явно не может положительно сказаться как на скорости рендеринга страницы, так и на скорости реакции на действия пользователя
— Делает то, что захотел автор библиотеки, а не то, что нужно прямо сейчас для конкретной задачи
— Содержит неизученные доселе баги, поскольку с существующими я знаком и почти все они описаны
…посему — вам удачи. И жду топика «Вот я сделал» большой сложный проект на основе IE8.js и у меня всё работает» — тогда искренне за вас порадуюсь и, возможно, пересмотрю свою точку зрения. А пока — совершенно справедливо решаю для себя, что это игрушки.
А хабрапионеры © наверняка ломанутся подключать к своим домашним страницам 38 килобайт кода только для того, чтобы сделать закруглённые уголки, ибо кто сейчас владеет на практическом уровне CSS3-техниками? Правильно — единицы.
Резюмирую.
Я не готов отдавать свою вёрстку на растерзание скриптам, которые:
— Исправляют даже те особенности IE, которыми я могу не пользоваться в отдельном проекте
— Загружают память IE довольно большим массивом данных, что явно не может положительно сказаться как на скорости рендеринга страницы, так и на скорости реакции на действия пользователя
— Делает то, что захотел автор библиотеки, а не то, что нужно прямо сейчас для конкретной задачи
— Содержит неизученные доселе баги, поскольку с существующими я знаком и почти все они описаны
…посему — вам удачи. И жду топика «Вот я сделал» большой сложный проект на основе IE8.js и у меня всё работает» — тогда искренне за вас порадуюсь и, возможно, пересмотрю свою точку зрения. А пока — совершенно справедливо решаю для себя, что это игрушки.
А хабрапионеры © наверняка ломанутся подключать к своим домашним страницам 38 килобайт кода только для того, чтобы сделать закруглённые уголки, ибо кто сейчас владеет на практическом уровне CSS3-техниками? Правильно — единицы.
Я не готов отдавать свою вёрстку на растерзание скриптам, которые:
— Исправляют даже те особенности IE, которыми я могу не пользоваться в отдельном проекте
Ваше право. Но если кто-то посчитает такие жертвы допустимыми, то это его право.
— Загружают память IE довольно большим массивом данных, что явно не может положительно сказаться как на скорости рендеринга страницы, так и на скорости реакции на действия пользователя
Вот здесь вы снова на грани голословности. Или вы уже успели за ночь проанализировать потребляемые этой библиотекой ресурсы?
— Делает то, что захотел автор библиотеки, а не то, что нужно прямо сейчас для конкретной задачи
Мало ли что умеет браузер. Я бы не стал жалеть о том, что браузер умеет больше чем мне нужно. Хотя конечно немного не по себе от того, что до сих пор бессмысленно использовать для тех же скруглений border-radius поскольку самый массовый браузер не работает с css3
— Содержит неизученные доселе баги, поскольку с существующими я знаком и почти все они описаны
А я как раз уделил внимание изучению этих багов. За последние пол года не было ни одного случая, когда баги библиотеки ставили непреодолимые препятствия.
жду топика «Вот я сделал» большой сложный проект на основе IE8.js и у меня всё работает» — тогда искренне за вас порадуюсь и, возможно, пересмотрю свою точку зрения.
Вряд ли я буду называть IE8.js основой для проекта, но если не забуду — извещу вас о том, что какой-то довольно сложный код успешно работает с применением этой библиотеки и не "падает".
А пока — совершенно справедливо решаю для себя, что это игрушки.
Вы снова не отвечаете за свои слова. Справедливыми вы сможете назвать свои выводы только после того как обнаружите пагубное влияние указанного кода. До того момента на справедливость и объективность такого утверждения претендовать нельзя. Кстати "Для себя" это прямой синоним понятия "субъективно" и стало быть ему нечего делать в одном предложении с "совершенно справедливо".
А хабрапионеры © наверняка ломанутся подключать к своим домашним страницам 38 килобайт кода только для того, чтобы сделать закруглённые уголки,
Может вам кажется, что подключать для этой цели 86kb jquery+jquery.corner более оправдано? Как видите скругления достаточно востребованы и указанный способ реализует их с посощью css2 безо всякого javascript. Библиотека же нужна для того, чтобы нынешние версии IE тоже могли работать с css2 в большем объеме, чем сейчас. А с выходом IE8 эта библиотека самоустранится за ненадобностью (если IE к тому времени не растеряет своих пользователей). Так что подключение библиотеки Эдвардса может оказаться вполне оправданным способом облегчения труда веб-дизайнера(верстальщика) и 38кб это не такая уж высокая плата за сэкономленное вермя и достигнутые результаты. Тем более в наше время, когда jquery могут подключать просто ради анимации выпадающего меню.
ибо кто сейчас владеет на практическом уровне CSS3-техниками?
Стоит ли напоминать, что :before и :after относятся к спецификации CSS2, которая вышла в 1998 году? Если кто-то за 10 лет не разобрался, то это уже не наша с вами проблема, чтобы об этом переживать. А вот если CSS2 станет более популярен благодаря тому, что IE можно заставить его соблюдать, то я не вижу в этом ничего плохого.
У меня такое ощущение, что я своей попыткой разобраться почему-то вас расстроил.
Тут к гадалке не ходи — 38 кб (90 в несжатом) кода, которые занимаются парсингом CSS-файлов и динамической вставкой объектов, в любом случае занимают в памяти приличное место. И это не голословное утверждение.
Речь идёт не о «жалко-нежалко», а о том, чтобы подключать к станице какой-нибудь несжатый Prototype.js _только ради лайтбокса — это не «жалко-нежалко» — это глупо.
Вот и здесь — если использовать это чудо только для скруглённых уголков, это стрельба из воробья по пушкам )
Вы удивитесь, но я ни в коей мере не претендую на какие-то объективные заявления. Зачем мне думать за других, я лучше выскажу своё мнение. Услышат, поймут — хорошо. Нет? Ну, не говорите, что я не предупреждал…
Мне кажется, что Plain Old HTML — <div class="tl"><div class="tr"><div class="bl"><div class="br"> — как нельзя лучше и главное быстрее будет рендерится браузером.
А вообще, я скорее сторонник graceful degradation, когда для IE6-7 отдаются кубики, а для IE8 (с поддержкой генерируемого содержимого) — скруглённые фигуры. Но это разве что на личных проектах. В реальной работе это не прокатит.
Вот здесь вы снова на грани голословности. Или вы уже успели за ночь проанализировать потребляемые этой библиотекой ресурсы?
Тут к гадалке не ходи — 38 кб (90 в несжатом) кода, которые занимаются парсингом CSS-файлов и динамической вставкой объектов, в любом случае занимают в памяти приличное место. И это не голословное утверждение.
Мало ли что умеет браузер. Я бы не стал жалеть о том, что браузер умеет больше чем мне нужно.
Речь идёт не о «жалко-нежалко», а о том, чтобы подключать к станице какой-нибудь несжатый Prototype.js _только ради лайтбокса — это не «жалко-нежалко» — это глупо.
Вот и здесь — если использовать это чудо только для скруглённых уголков, это стрельба из воробья по пушкам )
Кстати "Для себя" это прямой синоним понятия "субъективно" и стало быть ему нечего делать в одном предложении с "совершенно справедливо"
Вы удивитесь, но я ни в коей мере не претендую на какие-то объективные заявления. Зачем мне думать за других, я лучше выскажу своё мнение. Услышат, поймут — хорошо. Нет? Ну, не говорите, что я не предупреждал…
Может вам кажется, что подключать для этой цели 86kb jquery+jquery.corner более оправдано?
Мне кажется, что Plain Old HTML — <div class="tl"><div class="tr"><div class="bl"><div class="br"> — как нельзя лучше и главное быстрее будет рендерится браузером.
А вообще, я скорее сторонник graceful degradation, когда для IE6-7 отдаются кубики, а для IE8 (с поддержкой генерируемого содержимого) — скруглённые фигуры. Но это разве что на личных проектах. В реальной работе это не прокатит.
У меня такое ощущение, что я своей попыткой разобраться почему-то вас расстроил.
Нет, для меня правота не так важна как эффективность. Так что если вы меня отговорите, то я не буду обижен.
Тут к гадалке не ходи — 38 кб (90 в несжатом) кода, которые занимаются парсингом CSS-файлов и динамической вставкой объектов, в любом случае занимают в памяти приличное место. И это не голословное утверждение.
Это именно, что голословно. Поскольку никаких тестов вы не проводили и чужих не видели. Вы лишь предполагаете, что этот код нагрузит браузер какой-то работой, но о том допустимой ли будет эта нагрузка вы пока судить не можете.
Речь идёт не о «жалко-нежалко», а о том, чтобы подключать к станице какой-нибудь несжатый Prototype.js _только ради лайтбокса — это не «жалко-нежалко» — это глупо.
Вот и здесь — если использовать это чудо только для скруглённых уголков, это стрельба из воробья по пушкам )
На мой взгляд библиотека, которая в разных проектах грузится хотлинком из одного места и кешируется браузером способна принести экономию трафика перед простым четырехкратным вложением блоков для каждого скруглённого блока каждой страницы со скруглениями. Так что говорить про экономию можно только в аспекте производительности, а этот момент, как мы с вами выяснили, тоже нельзя оценивать теоретически. В данном случае абсолютно справедливо утверждение "Практика — критерий истины". Только она может показать кто прав.
Вы удивитесь, но я ни в коей мере не претендую на какие-то объективные заявления. Зачем мне думать за других, я лучше выскажу своё мнение.
Совершенно верно. Однако выражая субъективное мнение не нужно использовать выражения "совершенно справедливо", "Мне слегка лениво проводить тестирование насколько IE6 будет вешаться от подобных манипуляций...Делаем вывод — это игрушка", "Содержит неизученные доселе баги" и прочие утверждения, не опирающиеся на факты.
Мне кажется, что Plain Old HTML —— как нельзя лучше и главное быстрее будет рендерится браузером.
Вы часто встречаете ситуацию, когда разница в скорости рендеринга в IE настолько заметна, чтобы этот аргумент вообще учитывать?
Вы часто встречаете ситуацию, когда разница в скорости рендеринга в IE настолько заметна, чтобы этот аргумент вообще учитывать?
К сожалению, довольно часто. Почти любой лайтбок (fancyZoom особенно) довольно сильно подвешивает IE, если бегать мышкой по странице довольно активно. Подмигивающий курсор — один из самых явных признаков.
Ладно, будет вам тестирование, если вопрос встал так принципиально.
Я тоже когда-то так обжегся. Но для начала сравните условия. Вы пользовались старой альфой от ie7.js, а я сейчас использую 3 бету IE8.js (которая сильно отличается в лучшую сторону)
Кроме того я отлично знаком с тем фактом, что от всех хаков IE избавиться не всегда получается. Однако два сделанных с использованием этой техники проекта (не таких уж и мелких) показали жизнеспособность нынешней версии этой библиотеки.
Брать уже готовую верстку и вставлять туда IE8.js конечно же нелепо. Поскольку гарантировано придётся что-то переделывать. А вот когда начинаешь писать код с ней с нуля, результат становится значительно лучше, чем без неё.
Кроме того я отлично знаком с тем фактом, что от всех хаков IE избавиться не всегда получается. Однако два сделанных с использованием этой техники проекта (не таких уж и мелких) показали жизнеспособность нынешней версии этой библиотеки.
Брать уже готовую верстку и вставлять туда IE8.js конечно же нелепо. Поскольку гарантировано придётся что-то переделывать. А вот когда начинаешь писать код с ней с нуля, результат становится значительно лучше, чем без неё.
На практике соизмеримо со средней картинкой. Даже логотипы у некоторых бывают тяжелее.
Картинка никак не действует на работу бразера, она просто грузится и все, в отличии от js файла
Кстати для рядовых разработчиков библиотека Эдвардса может стать тем самым коспромисным решением, которое облегчит и ускорит работу за счёт удовлетворительного, хотя и не оптимального обращения с недостатками IE6. Такой подход вполне может остудить страсти вокруг жестких санкций по отношению к пользователям IE6 (и ниже) всего лишь заставляя их некачественные браузеры подгружать такой себе "патч" на 38кб.
А нам сегодня многоуважаемый Андрей Сумин показал занимательные углы на beta.ya.ru:
http://new-features.ya.ru/ (те что внизу в боковых блоках) из одной точки :)
http://new-features.ya.ru/ (те что внизу в боковых блоках) из одной точки :)
К сожалению, сделать такое же с рамочкой произвольной толщины не получится. Но за изобретальность — 5…
Такими штуками нужно максимум рисовать Гомера Симпсона )
Это не точка, это буллит. «•» Такие вещи очень нестабильны, читай зависят от шрифта. Причём не только размер «кружочка», но и его положение относительно базовой линии.
::before ужасает, ибо в javascript нет нормального способа считать css, только подгрузить ее через XMLHTTPRequest и парсить самостоятельно. Это даст сущесственные тормоза на сайтах со сложной версткой и где много цсс фалов сжимается в один. В общем библиотека Эдвардса видимо пригодна только для сайтов визиток.
Чета мне сцыкотно стало...
пока не стал разбираться в реализации, так поверхностно глянул — очень понравилось.
в избранное однозначно + наверно буду использовать в будущих проектах
в избранное однозначно + наверно буду использовать в будущих проектах
мой способ скругления с одной картинкой - http://rybakit.at.tut.by/containers/c.html
Да это известный метод. К сожалению как и у всех других у него есть свои недостатки — например обилие лишних тегов.
хорошо работает, спасибо
А вот тут выяснилось, что вы в примере лукавите ;) Если _вообще не указывать размеры блоку, то в IE6 всё взрывается… И это вполне реальная ситуация, когда нужно резиновому блоку нужно задать пиксельные отступы.
Однако всё чинится, если задать процентную ширину. Минус один пункт в гибкости…
Продолжаю тестировать.
Однако всё чинится, если задать процентную ширину. Минус один пункт в гибкости…
Продолжаю тестировать.
40 объектов на странице, IE7 системный, IE6 standalone, скрипт в закеширован.
После обновления страницы показываются квадратные блоки, которые скругляются через…
— IE7 порядка 5-ти секунд
— IE6 порядка 9-ти секунд
…при этом использование CPU на время работы подскакивает до 25%, но в конце снижается обратно.
Т.е. если мы закругляем просто макетные блоки в количестве 5-ти штук, то рисоваться это будет секунду-две, а если у нас на странице каталог телефонов и каждый в скруглённом блочке, то мы обречены на 10 секунд невозможности взаимодействия с браузером.
Дальше:
40 объектов на странице, IE7 системный, IE6 standalone, скрипт в закеширован.
К странице подключен CSS-файл http://www.livejournal.ru/s/style.css в почти 6 000 строк кода.
Обновляем страницу, видим:
— IE7 скругляет порядка 15-ти секунд, процессор на время рендеринга загружен на 100%
— IE6 думает порядка 5-ти секунд и не скругляет
…оба браузера показывают ошибку: Line 3, Char: 7495, Error: Syntax error
Т.е. если наш проект представляет собой не домашнюю страничку с 50-ю строками в CSS-файле, а полноценный портал, то время рендеринга таких блоков возрастает до неприличия, загрузка процессора взлетает до 100%, а IE6 вообще отваливается — судя по всему, на этапе парсинга CSS-файла.
После обновления страницы показываются квадратные блоки, которые скругляются через…
— IE7 порядка 5-ти секунд
— IE6 порядка 9-ти секунд
…при этом использование CPU на время работы подскакивает до 25%, но в конце снижается обратно.
Т.е. если мы закругляем просто макетные блоки в количестве 5-ти штук, то рисоваться это будет секунду-две, а если у нас на странице каталог телефонов и каждый в скруглённом блочке, то мы обречены на 10 секунд невозможности взаимодействия с браузером.
Дальше:
40 объектов на странице, IE7 системный, IE6 standalone, скрипт в закеширован.
К странице подключен CSS-файл http://www.livejournal.ru/s/style.css в почти 6 000 строк кода.
Обновляем страницу, видим:
— IE7 скругляет порядка 15-ти секунд, процессор на время рендеринга загружен на 100%
— IE6 думает порядка 5-ти секунд и не скругляет
…оба браузера показывают ошибку: Line 3, Char: 7495, Error: Syntax error
Т.е. если наш проект представляет собой не домашнюю страничку с 50-ю строками в CSS-файле, а полноценный портал, то время рендеринга таких блоков возрастает до неприличия, загрузка процессора взлетает до 100%, а IE6 вообще отваливается — судя по всему, на этапе парсинга CSS-файла.
Если опустить проблему с ИЕ, то метод мне показался гениальным. Отлично!
Спасибо воспользовался
работает на Firefox и Safari без проблем.
быстро, просто, удобно!
работает на Firefox и Safari без проблем.
быстро, просто, удобно!
главное без гемора :) спасибо..
Скрипт Эдвардса почему-то во всех случаях, когда я пытался его использовать работал гораздо хуже, чем пара лишних элементов и несколько строчек хаков в conditional comments... Мне никогда, к сожалению, это не помогало...
Видимо, 40-й, юбилейный, способ с немного расширенным функционалом fantactuka.net/canvasul/, описание habrahabr.ru/blogs/webdev/37259/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
39-й способ скругления блока. Один тэг, одна картинка.