All streams
Search
Write a publication
Pull to refresh
15
0

Пользователь

Send message
Жизнь вообще штука сомнительная, а что то делать в ней, — тем паче, обязательно спросят — Зачем живешь?
Aingis? Собственно разные выключалки на ява-скрипт много делал, Вашу видел тоже, — неплохо, — но мне захотелось разнообразия, Имхо тут, мне кажется, в полемике, именно ваша работа, реагирующая на «фокус на элементе даёт о себе знать.
Piterski:, Вот интересный пример через этот же псевдокласс
Это прошлогодний наш вариант, неудобства были описаны:
посколь тег label приводил к необходимости прописывания в каждом экземпляре input в спойлере нового ID, что создавало лишние «движения» серверу.
Carduelis,
C оберткой в label нельзя выстроить конструкцию css скрытия, (*если только не обернуть весь спойлер, тогда кликнуть, к примеру по ссылке в его контенте нельзя без скрытия… Тут на затее не одна голова была сломана
Хм, интересно как бы реагировали на самолёт Райтов начале 20 века? Подобного рабочего варианта чисто на сss в инете не найдено, Надо отметить, что мучительные искания работоспособной версии кода вызвало изъятие <label> из использования в спойлере перед чекитом, посколь тег <label> приводил к необходимости прописывания в каждом экземпляре input в спойлере нового ID, что создавало лишние «движения» серверу.
frol, Kubuntu 12.04 — нет к сожалению, но в ХP и Win7-8 работает

image
Aingis:,«Чистым» такой код невозможно назвать
«Чистым» был назван согласно замыслам статьи использовать только теги HTML и css. Вчитывайтесь в замысел топика, иначе минусы за мои вкусы зимой — как то авторитарно!
Aingis: появляется лишняя точка фокуса
А это плохо? — Вероятно кто-то найдёт это нужным
Собственно спойлер проходит обкатку в постах на форумах.
Aingis, не буду спорить, кому то зимой захотелось свежих огурцов, но зимой это не кошерно, нарушает установленный распорядок. Вот просто под Новый год, когда все заботы висят, захотелось отойти от обыденного…
Carduelis, сенкс
demimurych Собствено споры лишь о том — Что экономичней — делать проверки в каждой операции добавки-изъятия или по событию? -Если операций много и разных — возможно работа по единственному событию «onresize» — удачнее многочисленных проверок. Применение может быть обосновано и при употреблении чужих скриптов и библиотек, разбираться в которых нет времени.
mank_devно: и вследствие изменения размеров
Тут с подобной необходимостью можно столкнуться и при масштабировании окна браузера колёсиком мыши, хотя масштаб можно отследить и по window.onresize окна браузера.
Задержка выбрана из минимального времени срабатываний setTimeout браузеров: — для настольных ПК она порядка 10-12ms, для мобильных устройств порядка 20ms.
Первичной задержка по загрузке iframe 20ms или 200ms -не критична, посколь столь быстрое «onresize» вряд ли отследить взглядом.
Задержка для устранения быстрых срабатываний, наверно болеее критична, (исследовалась только для браузеров на ПК), в большинстве случаев приведённая цифра — устраивала.
demimurych, Спасибо за чувства. Но имхо суть топика: Ранее методов отслеживания близких к реальному «onresize» на произвольном элементе — не было. Использовали и используют таймер, несмотря на некое недоумение неявоскриптёров.

Тут предлагается практически равноценный аналог «onresize» на произвольном элементе. Нужность — не нужность оценится уже практикой применения. Ранее jQuery — не было, сейчас многие без оной не представляют верстку. т.е.- Есть вариант новой стамески, а «пользоваться — не пользоваться?» — решать Вам. Возможно круглая с фаской Вам не подходит(но для кого-то востребована.)
Approved_by_Biolanteнаписал(а):
Легко — я процитирую комментарий:… вы если контроллируете страницу можете узнать когда вам необходимо проверить кусок ДОМа на ресайз. Предположим, вы загрузили контент динамически, проверили размер элемента и выстрелили бы событие один раз.
Это отличный вариант при заранее известном ограниченном кол-ве Аякс-подгрузок.
Представьте подгрузку RSS ленты на Инфо-сайт из пяти-шести источников одновременно короткими месагами. Они могут грузиться в один общий блок своими подблоками и делать проверку из каждой Аякс-подгрузки не айс, и она мало что даёт к общей картине. Однократное срабатывание «ресайза» айфреймом на общем блоке, позволяет общаться для правки лишь с последним подблоком.
demimurych написал(а): практический пример, где нужно контролировать «onresize» на элементе

Расползся элемент верстки из-за длинной строки,
При вставке Аяксом убежала колонка, не расчитанная на длину контента,
При анимации нужен контроль уменьшения/увеличения элемента более предельных значений( ограничиваем min-height/min-widh у фрейма(или max)
Движущиеся блоки выходят за границу контейнера, (*ставим фрейм на контейнер
Вместо ставить минусы — отпишитесь и предложите свой, иной вариант, кроме стандартного периодического тестировани по таймеру.
Собственно резюме:
Основной( и единственный) метод ранее, — периодическое тестирование размеров элемента по таймеру, через краткий промежуток времени, и достаточно ресурсоёмкий, и оставляет достаточно много «мусора» в памяти, вследствии постоянного воспроизведения своих функций и параметров.
Предложен новый вариант, позволяющий привязать событие «onresize» к произвольному элементу, чего ранее не было.
Данный код короче и, по своей идее привязки к конкретному элементу, — более прозрачен и менее ресурсоёмок для малого количества обследуемых элементов.
Vest сказал(а): Предположим, вы загрузили контент динамически, проверили размер элемента и выстрелили бы событие один раз.
Это тоже можно сделать двояко:
1. После первого срабатывания — мы обычно проводим модификацию расположения контента, к примеру отрезаем лишнее и переносим в соседнюю колонку, туда нужно перенести (или создать новый, удалить старый iframe и заново настроить событие (так что второго срабатывания не будет).
2. Вариант два: отключать проверку на «ресайс» во время загрузки контента, в течении данного Aякс-запроса и включать по окончании.
так вот бета Файерфокс выстрелил алерт два раза,

у FF(не только бета ) процесс установки размеров фрейма проходит два этапа — дефолтный размер, только затем размер указанный в теге, поэтому можно либо установить frame.onresize с небольшой задержкой, либо запретить срабатывание на время 10-20ms
Второе: — Ширина/высота может изменяться медленно и динамически, поэтому применяется такой приём:

<div  id="Test" style="position:relative;border:red solid 1px;width:200px;height:100px;">
<iframe name="frame" width=100% height=100% style="position:absolute;z-index:-1"></iframe>
Тут контент ...
</div>


<script type="text/javascript">
var timerResize='first';
if(timerResize=='first')setTimeout('clearTimeout(timerResize)',20);

frame.onresize = function(){
  clearTimeout(timerResize);
  timerResize=setTimeout( function(){ alert('Размеры div #Test изменены.')},20)
}

setTimeout(function(){  //Тестовое изменение размера через 3сек. 
  document.getElementById("Test").style.width='100px';
},3000);
</script>

Что убирает слишком частые срабатывания при долгих и плавных или рывковых изменениях размера;

Пример в статье дан как основа метода, не углубляясь в стандартную методологию и тонкости кроссбраузерной работы с onresize ( посколь тонкости приёмов работы с window.onresize достаточно хорошо описаны и для FF и ИЕ, — остальные браузеры вроде вопросов не вызывали. У FF, до недавнего времени, применение onresize c овместно alert () без тайминга блокировки быстрых срабатываний вызывало фатальную ошибку), — ксать и onscroll точно так же)
))) — У кого-то уже работает Ccыль

Information

Rating
Does not participate
Location
Россия
Registered
Activity