допустим в документе есть список элементов

как при клике по элементу узнать его порядковый номер в списке дочерних элементов ?

Если через jQuery, то там есть метод $.index()
Демо: http://jsfiddle.net/Aliance/en653sza/

спасибо
но мне нужно без сторонних библиотек
только хардкор ))

Ну как бы можно посмотреть как в этой библиотеки оно реализовано и скопировать.
С ходу могу предложить минимум два решения:
1) Нужно найти parentNode у искомого элемента, далее найти массив дочерних элементов (childNodes) этой родительской ноды, и пройтись циклом  по этому массиву, чтобы узнать на какой итерации мы дойдем до искомой. Номер итерации и будет равен её положению.
http://jsfiddle.net/Aliance/en653sza/1/
2) Нужно подсчитать кол-во предшествующих соседних элементов ДО искомой ноды. Это количество плюс один и будет равно ее положению.
подробнее

вопрос еще так стоит - не проще ли просто добавлять в каждый элемент нужные данные data-
если в модели DOM нет простого решения

если например список элементов очень большой тогда предложенные тобой вычисления позиции могут затянуться ?

macdack, Ну и добавляй в элементы дополнительные атрибуты, если это возможно, какие проблемы? Добавлять их можно в атрибуты data-XXX="YYY". 
Тогда переход когда-нибудь на jQuery окажется еще более безболезненным. В принципе, если используется валидатор html, могут обнаружится проблемы с некорректными именами атрибутов, но на это разумно плевать или использовать правильный доктайп.

ksnk,  проблем нет датасет годится

просто хотел узнать нет ли чегото в ДОМе готового и быстрого

получается что датасет предпочтительней ?
недостатков в нем не видно, типа медлительности при огромных документах ?

jQuery вообще не рассматривается по причине того что проекты планируются не энтерпрайзные, а чисто для себя и чисто на вебките без микрософтов, а потом может и на асме, когда подрасту ))

например оч интересно синтезатор на веб-аудио-апи сделать



Это сообщение отредактировал(а) macdack - 2.9.2014, 17:20

Я сравнил 4 метода: jQuery.index() / jQuery.data() / native js parentNode.childNodes / native js previousElementSibling, самым производительным оказался второй. Мог где-то ошибиться конечно, но в целом вроде адекватно.

Если с data-* все понятно, то можно подсмотреть как в jQuery реализован метод $.index():


Ага, теперь видим разницу. Я предложил использовать previousElementSibling (IE > 8), которое выдает, видимо, только ноды тегов (тип 1), а в jQuery используется previousSibling, которые выдает вообще все ноды, в совокупности с фильтрацией по типу 1. Это и оказалось быстрее (вариант 5 по ссылке ранее), чем jQuery.index() (вариант 1). Но все же jQuery.data еще быстрее, можно подсмотреть ее реализацию и сделать на нативном JS и получить наиболее быстрое решение. Если интересно, в jQuery метод, отвечающий за это, выглядит вот так:

Добавил его в тестовое сравнение как пункт №6, но в итоге несмотря на ожидания он не победил. Почему - точно сказать не могу, но явно я что-то упустил. Внутри jQuery.data есть кеширование, видимо из-за этого.

Кому лень смотреть тесты, итог таков:
jQuery.index() - 9,869 операций в секунду
jQuery.data() - 16,558
native js parentNode.childNodes - 3,860
native js previousElementSibling - 7,014
native js previousSibling - 11,525
native js data-* - 11,852

списибо Aliance, но мне пока трудно читать чужой код
я пока делаю первую практическую работу - простейший редактор текста

пожста попроще поясни почему нативная и жикверская data- различаются у тебя по скорости

скорее всего потому, что jQuery сперва проверяет наличие значения во внутреннем статик-кеше, и если его там нет - только тогда лезет в аттрибут к ноде, а затем его записывает в статик-кеш, чтобы при следующем обращении получить от туда быстрее. Получается, при одной итерации - jQuery вариант должен быть медленнее, из-за лишних операций. Но на дистанции оказывается быстрее за счет того, что вычисляет значение единожды. Думаю перевес связан с этим. А jsperf прогоняет тесты многократно, соответственно кеш срабатывает. Если бы сравнивалась скорость одной итерации - нативный вариант должен был победить.

Ну да, так оно и есть. Исправил 6 пример с нативным data-* (см. ссылку на jsperf выше), итог получился следующим:
jQuery.data() - 16,155
native js data-* - 20,731

Добавлено через 1 минуту и 14 секунд
Соответственно, самый быстрый способ - №6:

Aliance, спасибо

пойду делать нативный data-

Не за что. В Вашем случае скорее всего хватит варианта без статик-кеширования, сомневаюсь что вы многократно будете высчитывать позицию какого-либо элемента. Кроме того наличие статик-кеша требует некого идентификатора, я в своем кода для примера ввел ID (в коде обращаясь через node.id), но в реальности скорее всего с этим будут проблемы, еще один мотив не писать статик кеша просто так.
Как-нибудь руки доберутся посмотреть как реализован механизм идентификации нод в jQuery...

Если ответ на ваш вопрос дан - вверху есть ссылка "Пометить как решённый", желательно не забывать ее нажимать.

оказывается почтишто что я придумал в этой теме реализовано в этой библиотеке - http://habrahabr.ru/post/235675/

Если кратко (на самом деле, очень кратко, но идею уловите, а подробности придут с кодом) и по сути: Ractive.js до ужаса прост и состоит из двух половинок:

Темплейты (читай «вьюшка»), в которых вы очень декларативно описываете, как ваша программа\компонент должна выглядеть.
Данные — собственно данные, которые нужно представить во вьюшке и то, как на них влияет внешний мир (взаимодействие пользователя и\или сетевых запросов).


Соответственно, после того, как вы описали темплейт, данные и куда это все это рендарить (обычно id DOM элемента на страничке),
Ractive.js обеспечивает (причем абсолютно бескорыстно и без вашего участия) двухстороннюю связь между этими данными и темплейтом.
Т.е., как только данные меняются, тут же реактивненько меняется ваша вьюшка, которая соответствует этим данным, добовляются нужные и удаляются устаревшие DOM елементы. Ну и в обратную сторону:
как только пользователь чем-то в ваше приложение потыкал — меняются данные.
И так по кругу. И все очень реактивненько.

Вы спросите: «А в чем же радость?»

А радость в том, что вы пишите короткий, понятный, декларативный код без миллионов ивентов (которые как обычно летают взад и вперед, а мы пытаемся их обсервить, биндить и т.д.).
А главное — нет никаких манипуляций с DOM! Мы не создаем новые элементы… мы не удаляем их из DOM…
мы фактически никогда не ищем какой-то элемент при помощи $(selector) — всё всегда под рукой.
Ractive выстраивает паралельный DOM точно так же как это делает React и производит только точечные манипуляции с DOM.
Никаких лишних движений, и поэтому работает очень быстро. Кстати чем Ractive лучше\хуже React — тема для отдельной статьи.

Всё просто: поменяли данные — поменялось отображение. Это общая идея библиотечки.