lexxcode
-
Posts
1,539 -
Joined
-
Last visited
-
Days Won
79
Content Type
Profiles
Forums
Calendar
Store
Everything posted by lexxcode
-
Это было прочтено и с первого раза внимательно. Но разве выше указанные методы сложны для удержания в голове?
-
Как по мне, то самый такой простой и очевидный метод для перевода целых чисел bin=>dec метод Горнера. bin{11001} 0*2+1=1 1*2+1=3 3*2+0=6 6*2+0=12 12*2+1=25 dec{25} А в обратную сторону dec=>bin делением на 2, если есть остаток значит записываем 1 если нет, то 0. dec{25} 25/2 = 1 12/2 = 0 6/2 = 0 3/2 = 1 1/2 = 1 bin{11001}
-
есть еще http://jquery-docs.ru/ на русском, но хозяин видимо подзабил, так, что там не все, что есть в офф документации.
-
Hoax, хватит уже писать пустопорожние сообщения!!! Пока предупреждение
-
эххх нельзя с этого раздела в гугл направлять.... <!DOCTYPE html> значит, что применен doctype html5
-
Все ниче было бы, если убрать "OPpA GanGnam Style", а так какофония вышла.
-
По поводу видео-уроков, не согласен. Видео-уроки это хорошо, просто все зависит от мышления и склада ума человека, кому-то проще прочитать, кому-то услышать, а другому увидеть. Не стоит так категорично к этому относиться
-
Ой ну ладно-ладно признаю, мне просто было леньки для примера клонировать таблицу))
-
А почему нет? Ведь это на время, та и вроде с поддержкой норм
-
ну так к примеру не претендую на правоту, конечно UPD: Хотя решение глючит, при попытке взять другую ячейку, даже в оригинальном примере, только не пойму почему UPD 2: уже решил))
-
Ну таблица может быть и не пустой и вообще это может быть вполне обычная таблица
-
s0rr0w, согласен на все 146%. Проучил нас и правильно сделал. Спасибо тебе)
-
Я, например, ожидал увидеть читабельную таблицу, которая еще и визуально имеет смысл. Но тем не менее решение крутое.
-
А я не тоже самое сказал? У меня крутилась мысль об elementFromPoint когда уперся в rowspan, но я не догадался привести таблицу к такому виду, я оказался зашорен тем, что таблица должна остаться читабельной
-
А какой смысл такого решения читерства? Чтобы применить это на деле, значит, придется клонировать таблицу приводить ее к такому попиксельному виду, искать ячейку твоим методом, получать индексы и обращаться уже к реальной таблице... Оно рабочее, только он "мир прогнул под себя", оно работает правильно только когда таблица в таком бяконом виде Хотя в условии не было, что это должно быть прям практическое решение xD
-
Но самое логичное применить спрайты.... А еще можно сделать прелоад на js в гугл вагон решений
-
А, что уж мне тогда говорить вообще
-
не понял о чем ты? у s0rr0w там по-любому наверное есть какое-то крутецкое решение, на которое мне мозгов не хватило
-
ну да, согласен. Тогда затраты на хитроумный поиск, в скопе займут больше времени, чем сразу построить матрицу А я вводил понятие физического кол-ва ячеек в строке и виртуального, то есть с учетом colspan. Я изначально получал вирт. кол-во для первой строки и сохранял, назовем ее tLen, это в свою очередь служит отправной точкой. А дальше сравнивал: Если (вирт. кол-во текущей строки == tLen), то значит там нет завязок с rowspan со строками выше, а ниже нас не интересуют. А если (вирт. кол-во текущей строки < tLen), то значит строки находящиеся над текущей связаны по rowspan с текущей. Ну, а дальше там уже поиск тогда
-
А я не сказал, что подход плохой. Просто я попробовал найти лучше Просто если есть возможность уйти от полного обхода, списков, массивов, не важно чего, то нужно уходить. Это так же как с сортировкой данных, если бы было безразлично, то все бы сортировали пузырьком, и не парились изобретением всяких хитроумных алгоритмов, для уменьшения блужданий по элементам, а следовательно и общего кол-ва итераций. ну и не постоянно, если оно уже попало в кеш, то естественно оно бы бралось из кеша, без проведения поиска по новой, ну кроме случая если изменилась таблица
-
mishka, у меня была первая мысль реализации на том же принципе как у тебя, с первоначальным обходом таблицы и создания доп. матрицы с указателями на ячейки. Но при таком подходе получается, что если таблица большая очень, то вот эта первоначальная инициализация будет проявляться заметной задержкой работы страницы. Ну и если вдруг в процессе жизни таблицы в нее еще добавятся строки и столбцы, то придется делать обход полный по новой. Я вот пробовал получать ячейку таблицы без первоначального обхода таблицы, а по запросу. Например если в запрашиваемой строке нету связанных ячеек по вертикали, то можно делать обход только текущей строки, а не всей таблицы, и вот эти промежуточные значения кешировать в матрицу. А вот если есть связь ячеек по вертикали, то тут вот я запнулся, реализовать, то можно, но у меня появились сомнения об оправданности такого подхода. Если есть связь по вертикали, то нужно подниматься построчно вверх, до того момента, пока не попадется строка у которой число (tr[n].cells.length + ?(colspan - 1)) == (tr[0].cells.length + ?(colspan - 1)), где n - номер строки, ? - сумма (мало ли вдруг у кого-то символ не отобразится), либо пока не дойдем до tr[0]. Далее уже из полученного массива строк строить карту ячеек и кешировать. Вроде бы тоже возможны ситуации когда обхода всей таблицы не будет, но не всегда, зависит от структуры таблицы и от того, что на момент запроса уже есть в кеше. В общем, что-то крутил мутил)
-
Все работает
-
Читайте про очистку float'ов (или потока, называют по разному). Тогда сами поймете в чем ошибка вашего кода
-
Все одинаково отображается
-
нет. да и не заведено как-то
