как вариант — сделать еще троттлинг, даже если сделать 100мс очень сильно сократится кол-во расчетов и обхода дерева элементов в случае скроллинга перетаскиванием ползунка скроллбара.
+ повысил до 250 элементов, объединив getFromTop и getFromLeft в один метод, сократив кол-во обходов DOM в два раза, странно что я сразу до этого не допер, а только в момент написания статьи=)
Кстати об иерархичности селекторов, планирую доработать этот момент, вспомнил про иерархичность уже после написания статьи, когда спать ложился, пасибо что напомнил^_^
Интересно, в случае если часть эл-та над областью скроллинга и часть под действительно будет возвращаться outside.
Может возвращать что-то из серии «exceeds-vertically»? получится если включены allowMixedStates будет возвращаться exceeds-vertically exceeds-horizontally если блок во все стороны выходит за пределы области видимости
Стесняюсь спросить, но все же, ткните меня пожалуйста носом в функцию которая будет выдавать мне позицию элемента относительно ближайшего элемента имеющего скроллинг, с учетом того что это не обязательно окно браузера.
Во первых: у меня и так голый JS используется в том месте
Во вторых:
Начнем, пожалуй, с определения того, что же для данного контекста является областью видимости.
Для моей задачи, а писал я плагин, в первую очередь, для удовлетворения своих нужд, областью видимости является ближайший родитель, имеющий прокрутку.
.getBoundingClientRect() получает позицию элемента относительно окна браузера пользователя, что уже не подходит в случае если если область видимости у нас — не окно, а какой-либо другой блок ниже по дереву DOM.
Во всяком случае сейчас сравнил цифры возвращаемые моим методом и .getBoundingClientRect(), последний возвращает левак какой-то, и я не горю желанием выяснять почему, ибо есть уже работающий вариант функции.
Неоднозначность я имел в виду — по RFC 1738 это path, но я то имел в виду домен.
А если я укажу строку index.com, ресурса такого я не помню, но однако видя .com лично я воспринимаю ее как домен, а некоторые воспримут его как исполняемый windows файл.
Неоднозначность как раз в том, что нельзя выдернуть некий линк ( даже не полный, не являющийся линком по RFC ) из контекста и однозначно сказать домен это или путь.
Вполне осмысленное название… parameter1, parameter2 , я же не знаю что точно придет в parameter1.
— его может не прийти вовсе.
— а может прийти строка, тогда имело бы смысл назвать эту переменную value ( ибо если param1 указан, то это сеттер )
— а для метода params это был бы key ( читаем параметр с указанным ключом )
— а если пришла строка в param2, тогда param1 стоило бы назвать key, а param2 — value
— а если в param1 пришел хэш, то тогда param1 надо назвать hash
Как посоветуете быть в этом случае?
Что же касается Array.prototype.join то array.join склеивает весь массив с 1 сепаратором.
А у меня:
1) Не массив, а хэш, Т.е. объект, а не массив.( хотя вот если память не изменяет join и у хешей есть )
2) Мне надо склеивать значения с разными сепараторами.
Это, я бы сказал, неоднозначность.
Ибо hosthame имеет ровно ту же структуру, что и filename, например,, и достоверно по неполному/неправильному линку не всегда можно определить домен это или путь.
В текущем случае, ya.ru, по-правилам, является filename, т.е. относительной ссылкой на файл ya.ru лежащий в той же директории.
НО! я то например подразумевал домен, в данном случае.
как обрабатывать такие непонятки — пока не определился.
+ повысил до 250 элементов, объединив
getFromTop
иgetFromLeft
в один метод, сократив кол-во обходов DOM в два раза, странно что я сразу до этого не допер, а только в момент написания статьи=)Конкретнее, на 170-200 отслеживаемых эл-тах появляются просадки.
Буду работать в этом направлении, решение, скорее всего, заключается в минимизации количества хэндлеров события
scroll
offsetParent
помог мне избавиться отparseInt( val, 10 )
.offsetParent
outside
.Может возвращать что-то из серии «exceeds-vertically»? получится если включены
allowMixedStates
будет возвращатьсяexceeds-vertically exceeds-horizontally
если блок во все стороны выходит за пределы области видимостиВо вторых:
.getBoundingClientRect()
получает позицию элемента относительно окна браузера пользователя, что уже не подходит в случае если если область видимости у нас — не окно, а какой-либо другой блок ниже по дереву DOM.Во всяком случае сейчас сравнил цифры возвращаемые моим методом и
.getBoundingClientRect()
, последний возвращает левак какой-то, и я не горю желанием выяснять почему, ибо есть уже работающий вариант функции.как там сделано уже не помню.
а о быстрых решениях написал и я и норлин, сообщения норлина не видел, у него там развернутее
если оны не заняты под другие нужды
Аккурат роутинг в ангуляе
Вот за что минус этому комменту?
А так, как я уже говорил — основной интерес в том, чтобы сделать самому. Хоть на текущий момент я уже и знаю по меньше мере 4-5 библиотек.
Неоднозначность я имел в виду — по RFC 1738 это
path
, но я то имел в виду домен.А если я укажу строку
index.com
, ресурса такого я не помню, но однако видя.com
лично я воспринимаю ее как домен, а некоторые воспримут его как исполняемый windows файл.Неоднозначность как раз в том, что нельзя выдернуть некий линк ( даже не полный, не являющийся линком по RFC ) из контекста и однозначно сказать домен это или путь.
Я то предполагал мочь обрабатывать всё.
parameter1
,parameter2
, я же не знаю что точно придет вparameter1
.— его может не прийти вовсе.
— а может прийти строка, тогда имело бы смысл назвать эту переменную
value
( ибо еслиparam1
указан, то это сеттер )— а для метода
params
это был быkey
( читаем параметр с указанным ключом )— а если пришла строка в
param2
, тогдаparam1
стоило бы назватьkey
, аparam2
—value
— а если в
param1
пришел хэш, то тогдаparam1
надо назватьhash
Как посоветуете быть в этом случае?
Что же касается
Array.prototype.join
то array.join склеивает весь массив с 1 сепаратором.А у меня:
1) Не массив, а хэш, Т.е. объект, а не массив.( хотя вот если память не изменяет
join
и у хешей есть )2) Мне надо склеивать значения с разными сепараторами.
Ибо
hosthame
имеет ровно ту же структуру, что иfilename
, например,, и достоверно по неполному/неправильному линку не всегда можно определить домен это или путь.В текущем случае,
ya.ru
, по-правилам, являетсяfilename
, т.е. относительной ссылкой на файл ya.ru лежащий в той же директории.НО! я то например подразумевал домен, в данном случае.
как обрабатывать такие непонятки — пока не определился.
Жаль плюсомета пока нету.