s0rr0w

Одним массивом обойтись можно, если допустимо использовать объекты. Нужно для начала сделать временный объект, который будет иметь структуру { title: titleValuel, price: priceValue }, а потом только уже делать push этого объекта в массив

Массив может не помочь, если у тебя разные товары находятся на разных страницах и в разных окнах браузера. Универсальнее всего сделать при помощи ajax'a и хранить данные на сервере в той же сессии. Т.е при нажатии на кнопку, передавать эти данные на сервер, в ответ получать массив со списком добавленных товаров. Можно еще хранить данные локально, в localStorage, но беда как всегда с ИЕ.

Лучше пусть станет грамотным верстальщиком, который знает XML, XSLT, XPath, DOM и другие полезные технологии

Это еще цветочки. Помяните мои слова, скоро CSS будет сложнее всех языков программирования вместе взятых. Вместо того, чтобы развиваться по пути усложненние - реорганизация - упрощение - усложнение ... w3c group выбрала путь бесконечного усложнения. Я недавно пришел к мысли, что absolute, fixed, float, table - это суть одного и того же. Это можно все заменить одним универсальным подходом. Это все легко заменяется xpath. Нафига они еще один огород городят, не понятно...

Не радуйтесь раньше времени, еще не раз вопросы задаваться будут...

Оскорбление? Требую доказательств сих слов!

Для начала советую изучить боксовую модель css (а если с английским хорошо, то лучше почитать тут) Обратить внимание на то, что к строчным (inline) элементам не применимы некоторые из свойств. Указать ему position: absolute и задвинуть отрицательным значением top за пределы экрана

Нужно? Вот и делай, раз нужно. onmouseover и onmouseout, или :hover width + height + padding + margin

Еще один защитник сирых и убогих появился... У тебя тоже с грамотностью проблемы?

Относится и к вашему посту тоже. Не перерастет, если не переходить на личности.

Флейм с упором на личности - негативный флейм. А тут мы мило беседуем.

Так зачем это писать в ответ на мои слова? Особенности человека таковы, что если нейтральные, общие слова его цепляют, значит он применяет их к себе и они находят позитивный отклик. Реакция нормального человека выглядит примерно так: "Спасибо за указанную ошибку, у меня с этим проблема, буду стараться использовать проверочные вопросы в дальнейшем". Реакция упертого невежды выглядит так: "Да вы все задолбали со своей грамматикой! Это форум HTML, а не русского языка!" В первом случае человек хочет стать лучше, а во втором - нет. Первые люди мне симпатичны, а вторые вызывают только жалость. Перед "что" запятую бы надо...

Где я срывался? Клевета и выдавание желаемого за действительное? Если не указывать на недостатки, то человек так и будет ходить невеждой. В школе учителя нужны как раз для того, чтобы помогать усваивать знания, акцентировать внимание на проблемах и проверять знания ребенка. Если кому-то нравится быть интеллектуально отсталым, то это не значит, что всем остальным приятна компания из таких людей. Задумайтесь о своем будущем. Потом еще спасибо скажете.

Обожаю людей, которые выпячивают свою безграмотность... Ограниченность и ущербность никогда не приводят к позитивным результатам. Быть глупым не зазорно, но это не достоинство, а недостаток. Задумайтесь, пока не поздно.

[grammar_nazi_on]Дрим что делаеТ? НравиТСя.[grammar_nazi_off]

Потому что все нормальные люди используют для этих целей json

Так это гугловские извращения, в спеке такого выпендрежа нет. Они нужны для защиты от переопределения. Например, у тебя есть объект по работе с денежными суммами. Пусть это будет кошелек. Например, процедура записи некой суммы в кошелек должна всегда производиться в самых минимальных денежных единицах: для долларов сумма записывается в центах, а для рублей в копейках. Так вот метод записи нельзя переопределять никогда, это должно быть приватный метод. Это гарантирует статичность поведения всех экземпляров объекта.

JavaScript - не классический ООП, в нем нет классов, он основан на прототипах. Это другой подход и другой мир. Например, в JS нельзя без извращений сделать свойства объекта приватными. Можно через замыкания, но это чревато проблемами. jQuery - синглтон. Плагины реализованы как обработчики основного объекта. В классическом ООП каждый плагин наследовал бы какой-то абстрактный класс jQueryPluginAbstract, и уже потом расширял бы его методы и свойства, но плагин в jq - это всего лишь инстанс. А подробнее можно, где там битовые операции...

Я не сказал, что объекты не нужны. Просто привычные для системных программистов "инкапсуляция", "полиморфизм", "наследование" в JS для меня смотрятся как припарка для мертвых. Попытка притянуть "чистое" ООП в JS лично я расцениваю как отсутствие гибкости мышления программиста. Шифрование тем хорошо, что алгоритмы шифрования скрыты от пользователя. Шифрование на JS - это как ключ от квартиры под половиком. Да и изучение битовых операций может лучше начать с матчасти. Например, самое быстрое целочисленное деление на 2 - битовый сдвиг вправо.

ООП в JS нужно по стольку по скольку. Максимум синглтоны использовать. Наследования и прочие системные плюшки банально никому не нужны. В слове JavaScript второе слово "Script" не просто так написано, это скриптовый язык изначально. Его предназначение - сценарии, а не написание операционных систем. Применять битовые операции нужно один раз на миллион. Удобно их в битовых масках использовать, например, для хранения прав. Больше особо негде. Не та область применения.

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

xpath-мышление в большинстве своем подразумевает движение под дереву от корня к детям. Путешествие по ветвям DOM-дерева практически отсутствует. Типичное мышление примерно такое: Для того, чтобы зайти к соседу, нужно зайти в дом, в нужный подъезд, подняться на нужный этаж и зайти в нужную дверь. Хотя можно было просто выйти на лестничную клетку и зайти к соседу. Очевидно, что проще последний вариант. Например, я часто использую поиск определенного контейнера, в котором находится нужная мне нода, т.е. двигаюсь по дереву вверх. Казалось бы, почему не применить id, и не перескочить сразу на нужную ноду? Не всегда это удобно и не всегда это полезно. XPath-подход сильно чувствителен к изменению структуры дерева и придется заплатить или постоянной модификацией запросов, или скоростью выполнения запросов. А создавать динамическое формирование query на лету, будет еще тем занятием, ведь для динамического запроса тоже нужно будет собирать данные, чтобы он работал быстро. Так не стоит ли вообще от него отказаться и не мучаться? Старье. Результаты самой свежей увидеть хочется

Выложите результаты бенчмарка, мне лень ставить оперу на машину.

Ничего не понял. Напишите еще раз и по-русски, пожалуйста. Используйте знаки препинания, чтобы построить предложение правильно.

Странно, что никто не задал вопрос, а почему же так плохо мышление а-ля xpath...