Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/27/2011 in all areas

  1. xpath-мышление в большинстве своем подразумевает движение под дереву от корня к детям. Путешествие по ветвям DOM-дерева практически отсутствует. Типичное мышление примерно такое: Для того, чтобы зайти к соседу, нужно зайти в дом, в нужный подъезд, подняться на нужный этаж и зайти в нужную дверь. Хотя можно было просто выйти на лестничную клетку и зайти к соседу. Очевидно, что проще последний вариант. Например, я часто использую поиск определенного контейнера, в котором находится нужная мне нода, т.е. двигаюсь по дереву вверх. Казалось бы, почему не применить id, и не перескочить сразу на нужную ноду? Не всегда это удобно и не всегда это полезно. XPath-подход сильно чувствителен к изменению структуры дерева и придется заплатить или постоянной модификацией запросов, или скоростью выполнения запросов. А создавать динамическое формирование query на лету, будет еще тем занятием, ведь для динамического запроса тоже нужно будет собирать данные, чтобы он работал быстро. Так не стоит ли вообще от него отказаться и не мучаться? Старье. Результаты самой свежей увидеть хочется
    1 point
  2. Вот на хабре статья была на эту тему - http://habrahabr.ru/blogs/javascript/130274/
    1 point
  3. Не если пиксель в пиксель то можно и пару дней покопаться. Если вы говорите что за 16 часов, то это либо вы убьёте на это все выходные, что врятли. Либо будете делать 3-4 дня. Для фриланса вполне нормально, но на самом деле быстрее делается. Я не фрилансер, я такой же "раб", поэтому адекватно оцениваю: 8 часов (я бы за столько это сделал в офисе) быстро, но врядли продуманно. 16 часов (я бы за столько это сделал дома как левак) - вполне нормально.
    1 point
  4. SelenIT, Ааа, т.е. выходит, что если я удалю элемент из ДОМ-а, то обратившись потом к нему в коллекции querySelectorAll(), я просто получу допустим undefined? Но при этом в этой коллекции он останется, да? Или, например, я удаляю элемент из ДОМ-а, но при этом из коллекции он всё равно НЕ удаляется? Как именно происходит?
    1 point
  5. А я вроде как никого и не назвал рабом, я высказал своё мнение, я так считаю. Я понимаю, что вёрстка у нас совершенно не ценится и что платить по 150 рублей за макет верстальщику - это уже в порядке вещей, но это не означает, что все должны с этим мириться и засовывать язык в попу, прислуживая жадным заказчикам, которые платят копейки и получают соответствующий кал. Я себя ценю выше, что ж поделать, извините.
    1 point
  6. 5000 рублей. Срок - Две недели. IE8+ Вы офигели что-ли? Две недели? 16 часов? Часов за 5-6 максимум такое верстается, ие7+. Бывает, что и два таких за день случается сделать. Вперёд Рабов ищи себе на фрилансе. Ну видимо я раб а че, 5000 за 5-7 часов работы, неплохо рабы зарабатывают
    1 point
  7. Любопытно раз это в комерческих услугах то за оценку денюшку дадут? если нет, то думаю место этой теме во флейме. P.S. Оффтоп: макет понравился, но для резины не очень подходит.
    1 point
  8. для <div class="content">...</div>, просто добавьте строчку в CSS .content {overflow: hidden;} читайте тут
    1 point
  9. Мне кажется, что это сделано не спроста, а для того, чтобы не просаживаться еще больше по скорости. Статический nodeList взялся из документации, в которой написано черным по белому querySelectorAll не быстры из-за того, что ему приходится перебирать ВСЕ или почти все ноды. Оптимизировать запрос можно, но это будет затратно по протребляемой памяти. Если бы он был еще и живым вдобавок, то простой скрипт модификации дерева по списку, который вернул querySelectorAll, запускал бы ровно столько процедур поиска, сколько и модификаций было. А так как граната в руках обезъян всегда стреляет, то решили на уровне спецификации не допускать бомбы в скриптах.
    1 point
  10. Продолжение беседы про мышление в стиле xpath тут
    1 point
  11. Продолжение темы Javascript > 108 атрибутов! Бенчмарк: http://jsperf.com/queryselectorall-vs-getelementsbytagname Картина одинаковая в Хроме и ФФ. На мелких проектах пофиг. Но на чем-то более серьезном этот тип мышления приводит к весьма противоречивому результату: вместо упрощения работы будет постоянная работа над оптимизацией запросов. И где профит?
    0 points
  12. DrStrangeLove оно то правильно!но нужен знак переноса!
    -1 points
This leaderboard is set to Kiev/GMT+02:00
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy