Получить координаты ячейки из <table>
 

Имеется таблица на чистом php
Хочу получить координаты ячейки по нажатию на нее в окне браузера.
Получается решить этот вопрос только двумя функциями, каждая из которых отдельно получает координаты строки и столбца.
Необходимо реализовать получение координат с помощью одной функции.
Когда пытаюсь объединить функции в одну, не получаю значение второй координаты:(
Я только начинаю делать первые шаги, но есть догадки, что при onclick функция не получает второй параметр:help: :help: :help:
Пример кода:

<table border="1">
  <tr onclick="myPositionY(this)">
    <td width="20" height="20" onclick="myPositionX(this)"></td>
    <td width="20" height="20" onclick="myPositionX(this)"></td>
  </tr>

function myPositionX(x) {
	alert("Координаты X: " + x.cellIndex);
}
function myPositionY(y) {
	alert("Координаты Y: " + y.rowIndex);
}

Помогите доступным языком разобраться чайнику :-?

О странной приставке, которая кочует из одного ответа в другой...
Для каждого элемента из пустого массива в контексте... Я не понимаю, зачем такое сложное для понимания перечисление нужно продвигать во многих ответах на этом форуме. Вот это странное [].forEach.call можно спокойно заменить на Array.from.

Array.from(row.querySelectorAll('td')).forEach(node=>node.onclick=myPosition);

Перечисление ещё можно(и даже грамотней с точки зрения JavaScript) организовать вот так...

for(const node of row.querySelectorAll('td')) {
    node.onclick=myPosition;
}

если не нужен ie < 12

:write:
или так

[...row.querySelectorAll('td')].forEach()

На вкус все фломастеры разные =). ИМХО любой работающий вариант достоин права на жизнь.
Но вещать обработчик на каждую ячейку это уже слишком. Думаю разумнее воспользоватся всплытием событий и повесить один обработчик на таблицу.

MallSerg,
а есть у вас какой-то минимально достаточный вариант делегирования?
(в учебнике есть, хотелось бы ваш вариант или какой другой, если можно)

странная приставка позволяет не создавать лишний временный объект (массив), что хорошо, ибо чем больше объектов, тем чаще придется собирать мусор

с другой стороны, может случиться деоптимизация forEach, потому что вместо работы только с массивами она становится полиморфной.

так что палка действительно о двух концах.

старый добрый цикл всё равно быстрее и экономичнее )

а сам forEach давно есть в прототипе NodeList (который создается методом querySelectorAll)

Нет конечно. просто у меня есть свое мнение =)

Вы конечно можете расширять прототипы как угодно, но сам интерфейс w3.org/TR/dom/#interface-nodelist не содержит такого определения (содержит только итератор, что достаточно для перечисления, добавление же методов от массива несколько излишне, поскольку некоторые методы не могут быть применены надлежащим образом. Например, метод sort от массива на самом деле не смог бы отсортировать ноды в представлении на экране, нужен именно особенный метод, который бы произвёл подобную сортировку. В большинстве случаев вам не нужна такая привязка, так что подойдёт любой способ перевода в массив (Array.from, или простое перечисление цикл for-of, for с переменной).)

w3.org - это теория )
на практике вот так - https://developer.mozilla.org/en-US/...deList/forEach

понятно что методы, которые меняют массив, будут там ни к селу ни к городу

Ну так в той статье, на которую вы ссылаетесь в конце как раз так и указано, что forEach является методом, который только в будущем возможно будет стандартизован (на developer.mozilla.org указывает, что это якобы Candidate Recommendation, на самом деле оно ссылается на черновик и при чём тут Web IDL? ) Т. е. оно поддерживается браузерами, но это не даёт никаких гарантии что это не будет удалено из реализации браузеров. (например, как это произошло с HTML imports)

Candidate Recommendation означает, что пришло время для реализаций и тестирования. Спецификация не может перейти на следующую стадию без подготовки полного набора тестов и создания как минимум двух независимых реализаций. Для forEach и iterator в NodeList существует более 2-ух реализации.

Это на самом деле очень огромная работа, связанная с разработкой API веб-языков.



Среди веб-разработчиков широко распространено ошибочное представление о том, что W3C выдаёт некие стандарты, которые должны быть реализованы бедными разработчиками браузеров, нравится им это или нет. Однако это заблуждение: что касается стандартов, мнение производителей браузеров имеет куда больший вес, чем пожелания W3C.

Также в противоположность распространенному мнению стандарты создаются не в вакууме, не за закрытыми дверьми. Например, рабочая группа CSS считает обеспечение доступности одной из важнейших своих задач, все её коммуникации полностью открыты для публики, и каждый свободен высказывать свое мнение и участвовать в обсуждениях.

Вопреки распространенному мнению, W3C не «делает» стандарты. На самом деле он играет роль форума, помогая заинтересованным сторонам собираться в так называемые рабочие группы W3C (W3C Working Groups) и проводить необходимую подготовительную работу. Разумеется, сам W3C также не остается простым наблюдателем: он устанавливает основные правила и контролирует процесс. Тем не менее фактическим написанием спецификаций занимаются (в основном) другие люди, а не сотрудники W3C.

P. S. developer.mozilla.org иногда содержит очень предвзятую информацию, например, может акцентироваться внимание, что что-то не поддерживается в Firefox, при этом умалчивается, что оно экспериментально поддерживается в других браузерах, не говоря уже о подтасовке (как вы уже знаете, как минимум две независимые реализаций должны существовать, чтобы что-то стало стандартом. В этом отношении, w3c, whatwg, tc39 являются более не предвзятыми источниками).

<table border="1" id="testTable">
  <tr>
    <td width="20" height="20"></td>
    <td width="20" height="20"></td>
  </tr>
  <tr>
    <td width="20" height="20"></td>
    <td width="20" height="20"></td>
  </tr>
</table>
<script>
testTable.addEventListener("click", ({target}) => {
  target.tagName === "TD" && alert(`Координаты X: ${target.cellIndex}\nКоординаты Y: ${target.parentNode.rowIndex}`);
})
</script>

Вариант :)