HeadShot

Смотрите в корень, а не по верхам хватайте. Проблема не в том, что надо кому-то или нет, а в том, что это в принципе невозможно сделать в текущем черновике. На тот, что JS позволяет вам делать все, что душа пожелает и так, как душа пожелает. И вы не ответили на мой вопрос, с технологией Flash знакомы? Аналогичного мнения. знаком

Не указывайте что мне делать, и я не буду рассказывать вам, куда идти. А чем это от JS отличается? Хорошо, задам вопрос по-другому, вы знакомы с Flash хорошо? Чем? Я люблю спорить фактами, не эмоциями и маркетинговыми лозунгами. http://lists.w3.org/Archives/Public/www-style/2012Jan/0816.html Вот вам кусок обсуждения. Анимация делается только на те свойства, которые можно инкрементировать арифметическими операциями. Но, у вас не получится плавно выйти из состояния display: none в display: block по окончанию анимации. Другими словами, если вам вдруг приспичит плавно уменьшить opacity с 1 до 0, а потом вообще убрать блок из потока, то с текущей спецификацией это сделать нереально. Другими словами, анимация на данном этапе развития ущербна по своей сути и годится для самых примитивных случаев. А для каких целей мне выходить плавно из состояния display:none в блок? Для чего visibility, position и z-index? Или вы считаете, что пин-понг является лучшей практикой? CSS правило существует уже в том момент когда загрузился CSS. На кой хрен это делать на JS?

С тех самых пор, как, так называемые слоупоки, сделали(приняли) механизм лучше. Я не говорю про канвас в этом контексте. Нужно понимать, что некоторые вещи делаются проще и лучше так, а некоторые по другому.

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

Щито? HTML - это структура CSS - это представление JS - это поведение Куда уж проще? Но нет, ребятам из W3C и таким как вы, HeadShot подавай адскую смесь представления и поведения. Вот нахрена, спрашивается, запихивать в CSS анимацию? Чем JS не угодил? UPD: А еще анимировать обычно надо не просто так, нужно делать это при наведении мышки, клике, иных действиях пользователя. Так может запихать в CSS еще и событийную модель? Чего уж там... Да, именно таким как мне хочется управлять состояниями( назовем их классами, которые бы отвечали за анимацию ), а не перерисовывать все что можно, там где не нужно на JS. Еще вопросы? Sorrow, Вам бы подлечиться p.s.: взгляните на кейфрэймы

Достаточно глупая затея. Люди там ковыряютя в свой песочнице и чужое мнение слушать не сильно хотят. Даже если это мнение в сто раз лучше всего того, что они городят. Прошло дофигища времени, пока они дошли до элементарной вещи как направление потока и точки отсчета. У меня на эту идею ушла пара минут. Они на одну фичу больше придумали, но как мучительно долго они до этого шли... Вообще CSS3 - попытка скрестить ужа и ежа. Но такие гибриды нежизнеспособны. Я знаю как выкинуть из спеки половину всего того, что они нагородили, и заменить на одну простейшую фиговину. Все мои попытки донести до разума окончились неудачей. Не согласен. Это не попытка скрестить ежа и ужа — это приоритет на нативную поддержку, того, что делается костылями( тот же JS — костыль, но все дело в области применения и индивидуальном восприятии ). Присоединяюсь к каменту выше. Любопытно

>> Я доверяю тому, что вижу и чем пользуюсь. Ох, мужик ... я же покажу Только не сегодня

Не поймите меня неправильно, но эти господа доверия не внушают. Даже не смотря на какие-то льготные условия, стремно ... Что до битриксов — дело вкуса, но это не проще и не лучше, по факту. UMI вообще нечто непонятное. Уж лучше на WP линк поставить. >> Хотя многие студии так и остаются на опенсорсе не понимая, что этим отпугивают львиную долю клиентов. Бред какой-то. Есть вещи со всеми их плюсами и синусами, с любого ракураса ... И есть маркетинг

Макхост ... че за позор такие баннеры вешать?

Я уже все сделал, проблема была... черт знает в чем. Создавал поддомен без www, но он был доступен только с www, а потом все стало нормально. Лезть лучше не буду, т.к. работает и хорошо. HeadShot, CDN - это не то, что я имел ввиду. Именно это

google -> cdn

В общем поигрался с плагином, потестил скорость реакции. Для IE показатели очень хорошие, если ваш макет был грамотно свестран. Тест проводил из под вируалки с ограниченными ресурсами и 512мб памяти. В забеге участвовали перекрытия 20 селекторов по приоритетам(т.е. оверрайд через родителя и никаких богомерзких !important); Забег осуществлялся браузерами IE6 и IE8. Показатели обалденные при учете не слишком идеального расположения кода вызова. Переключение происходит очень прозрачно и я даже не смог уследить на глаз момента, когда нужна схема задействуется. Что касается современных браузеров, то там тоже все хорошо, если вы не используете слишком обширно CSS3. Я пробовал биндить transition на элементы которые должны менять размеры — работает шустренько и весьма гладко, выглядит забавно. Думаю в будущем эта опция будет на уровне автоматики. Есть еще один способ оттянуть ближе к нулю момент срабатывания переключателя(думаю, можно кэшить все что вывелось в head сплошным блоком и не заставлять движок каждый раз все пересчитывать). Как раз для ситуации с большим количеством CSS3. Вариант наверное не совсем идеальный, но башка может оказаться большой. Чтобы избежать лишних пробежек придумал так: создаем фэйковый контейнер, например <cssshemas> </csssschemas> пишем ему display:none и линки уже клеим в него. после первого срабатывания и по каждому следующему переключению, все содержимое в HTML виде кладем в хранилище. Таким образом следующие загрузки будут сразу выталкивать из кэша готовую схему. Немного не валидно, но это же динамически происходит, а для head природных контейнеров не придумали. Что стоит отметить? Этот вариант все же больше подходит для аккуратной верски(не для таблиц ибо это смерть рендера). Также организовывать обращения лучше по типу root -> id -> class | element | type. Сделаю пару примеров такой верски со схемами для CSS Switcher. Собсно, если есть идеи — выслушаю пожелания.

fixed

интересный вопрос.

Интересно как при такой сетке запихнуть баннер с баннерообменника, скажем в левую колонку? флэш гавно, остальное тюнится css ом

пасиб, мужик

Ну вот резина вроде как хороший вариант. еще min-width не хватает

беру из головы

Спасибо, учту. Но ведь пихать мобильникам стиль заданный с помощью медиа запросов бессмысленно, тогда модели со старыми браузерами вообще не увидят этих стилей и будут подгружать десктопную версию. А если сперва сверстать для мобил, а потом добавить функционала десктопам с помощью медиа запросов, то старые браузеры увидят урезанную версию, а новые человеческую. У меня так и сделано - первый файл содержит стили для мобильников, второй для планшетов/десктопов. Для моделей с совсем старыми браузерами нужно все таки делать отдельную версию. Здесь стоит вопрос в целесообразности. Вряд-ли обладатель телефона с разрешением экрана 200х300 будет заинтересован в вашем сайте. Это просто звонилка. Большинство современных устройств позволяют сделать иначе и число их будет расти, а разрешения экранов становится если не больше, то всякие масштабировании точно будут прогрессировать. Где-то тут был ролик на тему прототипа айфона с проектором.

В том то и дело, что дополнительный стиль у меня большой и вносит огромные изменения (дело в том, что я верстал по принципу mobile first) и нужно чтобы он подгружался изначально, но потом его можно было бы отключить. Не понимаю как это реализовать. DOM -> таймер -> foreach( отключаем все кроме одного актуального ). Но это шляпа, будет медленно и дизайн будет танцевать. Видимо пересмотреть подход к организации каскадных таблиц. Обычно, для мобильников все лишнее делают в display: none и чуть манипулируют размерами контейнеров. Этого вполне достаточно.

Вот это было бы вообще замечательно. А ваш плагин может отключать один из стилей? То есть изначально у меня подключено два листа стилей (первый - мобильная версия, второй - стиль, добавляющий адаптивности) и чтобы люди могли выбрать подгружать ли второй стиль. Стоило написать об этом подробнее. Стиль не грузится пока не будет явно определено разрешение, либо пока пользователь не выберет нужный. Т.е. они как бы все готовы и все прописаны в документ, но фактической загрузки сразу-же не происходит. После того, как схема первый раз активировалась, стиль уже будет лежать в кэше. Если верстать аккуратно и с головой, то это очень не ощутимо т.к. дополнительные css должны описывать минимум изменений.

Можно, но после минификации это будет не очень ощутимо размеру. Все функции завязаны на одной логике и написаны так, что производительность не страдает(хотя и есть чего улучшить). Над конструктором подумаю. Как раз таки нет. Изначально идея была для переключения стилей и только. В прицнипе, могу переписать его на чистый JS. Вопрос лишь в свободном времени.

Извините, сразу не смог под 6ку верстку поправить(у виртуалки пробник закончился, пришлось купить), сейчас демка работает везде.

Спасибо!

спасибо, думаю пригодится