Решение JS-задачи про таблицу

[lexxcode]

ну так к примеру не претендую на правоту, конечно

UPD: Хотя решение глючит, при попытке взять другую ячейку, даже в оригинальном примере, только не пойму почему

UPD 2: уже решил))

[mishka]

ну так к примеру не претендую на правоту, конечно

Я тоже так(через класс) представлял это.

Но меня больше интересует то что если в ячейке будет полноценное содержание.

Ты это решил так:

.ch td *,
.ch th * {
    display:none;
}

Как-то стремно это юзать

[lexxcode]

Как-то стремно это юзать

А почему нет?

Ведь это на время, та и вроде с поддержкой норм

[mishka]

Да это какой-то путь джс-ниндзя.

Полезно знать, интересно. Но лучше по старинке протоптанными дорогами.

Я так попался раз на верстке. Тоже с помощью джедайских фишек сделал красиво и просто.

Но через время в опере(после обновления) вылез баг. Незнаю что подумал обо мне заказчик, но мне было оочень неприятно.

По поводу "временно". Бывают такие баги лезут, что только удивляешься.

Пример: на маке во льве, если блок с флешкой обрезается родителем -- флешка не проигрывается.

Казалось бы почему и и отчего? И на такие баги уходит немало времени.

Это "временно" тоже может чето сломать.

Было видео в блоке с бордеррадиусом, красивое скругление захотел клиент.

И это видео, так как его резал бордеррадиус, не проигрывалось.

Поэтому, всетаки, для експерементов это все полезно, но на практике.. может дать сбой.

[psywalker]

ну так к примеру не претендую на правоту, конечно

Я тоже так(через класс) представлял это.

Но меня больше интересует то что если в ячейке будет полноценное содержание.

Ты это решил так:

.ch td *,
.ch th * {
    display:none;
}

Как-то стремно это юзать

Ненене, реально это палево такое делать) Координаты таблицы меняются, а с ними и все координаты содержимого рядом, что не есть гуд. Тут клонировать нужно, однозначно.

[mishka]

Ненене, реально это палево такое делать) Координаты таблицы меняются, а с ними и все координаты содержимого рядом, что не есть гуд. Тут клонировать нужно, однозначно.

Ну да, с клонированием как-то надежнее. В теории

[psywalker]

Ненене, реально это палево такое делать) Координаты таблицы меняются, а с ними и все координаты содержимого рядом, что не есть гуд. Тут клонировать нужно, однозначно.

Ну да, с клонированием как-то надежнее. В теории

Ну да) с клоном точно пофиг, что будет)

[lexxcode]

Ой ну ладно-ладно признаю, мне просто было леньки для примера клонировать таблицу))

[s0rr0w]

Только клонирование. Но td * { display: none } нормальное решение.

Практическая задача - рисование таблиц через визарды

[nerv]

Всем привет )

Интересная задача. Ох уж эти объединенные ячейки

1. сомневаюсь, что клонирование + перестроение структуры DOM, будет быстрее нежели подход с матрицей

2. мысль alexriz про другой подход тоже пытался примерить, но пришел в выводу, что это не возможно

кстати, тут написано, что

Be careful about the elementFromPoint method!

In Internet Explorer earlier than version 8, the elementFromPoint method requires the parameters in physical pixel size, while from version 8, it requires the coordinates in logical pixel size.

What does it mean?

If the browser is not at the normal zoom level (the user has the ability to zoom in or out a web page: CTRL and +, CTRL and -), the elementFromPoint method works differently from version 8 than in earlier versions. The coordinates are required in the default pixel size in Internet Explorer before version 8 even if the current pixel size in the document is different. From Internet Explorer 8 and in Firefox, Opera, Google Chrome and Safari, the coordinates are required in the current pixel size.

For example, if the zoom level is 200%, the elementFromPoint method requires two times greater values before version 8 than from version 8 for the same point.

Fortunately, the clientX and clientY properties of the event object work similarly to the elementFromPoint method. They retrieve the mouse coordinates in the default pixel size in Internet Explorer before version 8 and in the current pixel size from version 8. For further details, please see the pages for the clientX and clientY property.

3. еще одна мысль на ночь глядя (без матриц и клонирования) основанная на все том же document.elementFromPoint()

// y
var rowCoords = $( table.row[ n ] ).offset();  // получить координаты строки относительно документа, в которой располагается искомая ячейка
var y = table.row[ n ].outerHeight() / 2 + rowCoords.top; // найти координату середины строки

// x
// найти строку, в которой содержаться все ячейки без пропусков
// например, это можно сделать обойдя все строки и проверив в которой из них больше всего ячеек
// отсчитать в ней нужное кол-во ячеек - 1(столбцов) и сложить их ширину
var cellsWidth += oneOfCells.outerWidth();
// добавить к ней половину ширины "искомой" ячейки (ищем центр)
cellsWidth += targetCell.outerWidth() / 2;
// из имеющихся данных получить x
var x = rowCoords.left + cellsWidth;

// ну и магическое
var cell = document.elementFromPoint( x, y );

но это все на ночь глядя и не 100% уверенности Кто-нибудь хочет реализовать? )

p.s.: в двух словах - тупо высчиитываем координаты относительно документа

Edited October 25, 2012 by nerv

[mishka]

что делать при резиновой или адаптивной верстке?

Пересчитывать все это снова при ресайзе?

Или при изменении размера шрифта?

[nerv]

что делать при резиновой или адаптивной верстке?

Пересчитывать все это снова при ресайзе?

Или при изменении размера шрифта?

разумеется, также, как и браузер Только, "все это" значительно более лояльные операции по сравнению с созданием матрицы и клонированием (на первый взгляд). Структуру DOM мы не меняем, просто собираем инфу. Только в отличии от матрицы, будет два цикла:

1. по строкам (а не строки х ячейки)

2. по конкретной строке до столбца n

Edited October 26, 2012 by nerv

[moron]

Даешь еще задачи!