s0rr0w

Странно что там используется древняя 8я убунта.

Нужно спецификацию внимательно читать, все там работает. item[begin=true] Это тоже работает. Я такое давно использую. ИЕ как всегда жжот. Очень сильно причем.

Чем помочь? Денег выслать? Проблем в отображением не вижу. У меня все работает нормально

Дай пример такого элемента.

Простейший пример Для примера возьмем простенькую задачу. Активируем нажатую ссылку путем присвоения класса "active". sampleDemo1.zip Теперь рассмотрим схему, как это все работает. При нажатии на каждую из ссылок мы запускаем событие activate, при этом присваиваем этому событию некий индекс. Значение события хранится в специальном контейнере SC.states. Далее, происходит перебор нод, из которых выбираются те, которые обрабатывают событие activate. Потом для каждой из нод запускается тот обработчик, который для данной ноды реагирует на нужное нам событие. Третья нода имеет параметр 3, а значение события у нас было равно 1, значит у этой ноды удаляется класс. Для второй аналогично. А вот для первой срабатывает выделение ноды. Вуаля! Логика программиста должна быть примерно следующая. Агрументы декларации (атрибут SC) обработчика (args) используются для того, чтобы идентифицировать некую ноду или создать некие входные параметры для обработчика. К примеру, можно модифицировать приведенный в примере обработчик, чтобы он не просто присваивал класс "active" ноде, а присваивал любой класс, который укажет разработчик. И тогда будет декларация выглядеть примерно так: SC="activateMenuItem:activate:1:myOwnActiveClass" Доступ к имени класса будет идти через scData.args[1].

Борьба с совестью? Похвально!

Хых. У тебя пять форм. Две заполнил, потом решил заполнить последнюю. В какую форму нужно давать подсказку, в последнюю или третью. Логически - в третью, со стремной логикой - в последнюю. Дабы была 100% определенность, при нажатии на кнопарь "подсказка", нужно показывать возле пустых форм дополнительную кнопочку, типа вот сюда хочу подсказку. Это самый адекватный метод, иначе все остальное имеет весьма сомнительную и слабопредсказуемую логику.

Вы изобретаете извращенный велосипед, которому требуются квадратные колеса. Никто еще до вас не требовал узнать, какой элемент получал фокус последним, потому что для этого есть onblur. Алгоритм моментальной проверки правильности введенного значения делается по onblur. Извращенный вариант - делать еще дополнительно проверку на onclick и onchange.

Странная задача...

Повесить всем инпутам событие onfocus, которое будет записывать в какую-то переменную ссылку на эту ноду. Хотя, опять же, нафига этот цирк?

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

Пофайлово не катит. Вызовы функций из библиотек как обфусцировать? Обфускация может быть следующей: * замена переменных и прочего в исходниках * компиляция исходников и декомпиляция через специальную прослойку на лету. Второй способ круче и дешевле в разработке, но потребует дополнительных телодвижений

Ну так и задачи разные бывают. Одно дело прикрутить контейнер, в который засовывается вся страница в HTML-виде, а второе дело сделать CMS ориентированную на данные. Самое страшное в любой CMS - система прав. Это можно было и немного по-другому монетизировать. Они получили продукт, который нужно все равно допиливать, неважно, какими способами. Ну так договорились бы, что в случае наступления доработок, они обращаются к Veseloff'у. Платит за доработки все равно заказчик. Так как 90% денег все равно им остается, поделиться 10% было бы выгодно всем. Тупые ребятки попались.

eval( 'array = {"type": "success", "data": "<div id="comment2" class="cBlock1" style="width:auto;*width:100%;margin-left:0px;">"}' );

Вроде да. Иначе ИЕ будет не ИЕ

Скорее всего никак. Ибо рендеринг завязан на новые системные функции.

Я бы назвал это extended DOM. Потому что Browser Object Model может описывать не только DOM, но и внутреннюю структуру самого браузрера. Неоднозначный термин получается.

Обработчики Обработчики в SC представляют собой функции, которые выполняют какую-то полезную работу при наступлении события, на которое они реагируют, и всех необходимых условий. Чтобы добавить обработчик в StateController, используется метод SC.addHandler. Первым параметром будет имя обработчика, вторым - собственно функция. Функции передается три параметра: * нода, на которой сработал триггер события * объект с декларацией обработчика у этой ноды (scData) * ссылка на объект data, который может быть установлен при вызове события. При запуске события был использован фильтр p: "parent", который ограничил зону распространения события всего лишь нодой контейнера. Так как сработали все необходимые нам условия, будет запущен обработчик foo4. Обработчик должен быть безликим. При создании обработчика помните, что он не ссылается на конкретные ноды, его код должен быть максимально универсальным. При соблюдении этих простых условий повторное использование кода может достигаться максимума.

В стандарте нет, но имплементация метода существует в браузерах.

А при чем тут ECMA?

Хаки + margin-right

Не всем так не повезло в жизни, как вам.

<td><img src="?"></a></td> Это чё?

Не все такие же как и вы. Мало того, метеорит, не астероид, может долететь только малая его часть до земли. И не во всех случаях придет полная гибель цивилизации.

Принципиальная схема работы SC отличается от любого другого фреймворка. StateController построен на событийной модели и оперирует такими понятиями как событие, обработчик, зона распространения события, объект обработчика и другими. Обработчики SC не являются обработчиками DOM, наступление события контроллируется разработчиком, а не браузером и пользователем. Если в том же jQuery работа с DOM начинается с поиска элемента или группы элементов, то в SC началом всего является запуск события. Событие в SC является неким пакетом данных, который запускают определенному набору элементов внутри одного или нескольких контейнеров. Пакет формируется в момент запуска события и его путешествие по дереву нод не останавливается до окончания обработки. Рассмотрим типичный набор данных, которые формируется при запуске события. Детальное описание можно прочитать в документации. Аналог из жизни может быть следующим. У вас в курилке сидят мужчины и женщины разных профессий. Вы - прораб. Вам пришло некое задание. Вы заходите в курилку и говорите, сегодня мне нужны маляры для покраски стен. На работу вызовутся, например, 4 мужчин и 1 женщина. Каждый из них возьмет кисточку, краски, и будут красить стены. Есть работа - событие. Параметр работы - покраска стен. Обработчики у каждого работника - покраска стен кисточками и краской. Если вам пришло задание сшить шторы, то вы должны запросить только тех людей, которые могут шить. Если вам нужны для работы только женщины, то вы ограничиваете дополнительными условиями, что нужны женщины, которые могут шить. Даже если в курилке все смогут шить, но выполнять работу будут только те, кто попал под определенные рамки. Следующая иллюстрация показывает примеры фильтрации нод при разных значениях фильтра. Фильтрация нод нужна по разным причинам. При огромном количестве нод внутри контейнера, скорость работы скрипта будет удручающей. Поэтому запуск события без фильтрации зоны распространения события желательно сводить на нет. Вторая причина - функциональное ограничение, когда намеренно ограничивается зона распространения события, чтобы не срабатывали дочерние обработчики или определенный набор обработчиков. После запуска события StateController выбирает некий массив нод, с учетом фильтра. Если фильтры не установлены, то выбираются все ноды внутри контейнера. Далее, из этого массива отбираются только те ноды, которые содержать атрибут SC. Среди этих нод выбираются те, у которых есть обработчики, которые реагируют на данное событие. И после этого запускаются обработчики для каждой из оставшихся нод. Если изменить фильтр, то некоторые ноды могут выпадать из списка обрабатываемых нод. Стоит помнить, что движение по дереву нод осуществляется от последней ноды к первой. При запуске некого события нет разницы, кто именно его будет отрабатывать и какие действия он будет при этом производить. Вы просто запускаете событие, а элементы сами разбирутся, кому что делать, делать ли вообще, что именно делать при этом событии. Программирование при помощи SC должно быть совершенно другим. Типичное мышления разработчика, который использует JQ сводится в общем к следующим этапам: найти элемент или группу элементов, проделать какие-то действия над ними. Если нужно, то найти еще группу элементов, и проделать над ними следующую порцию действий. Мышление разработчика, который использует SC совершенно иное. Есть событие, его нужно отправить группе элементов. Если по пути обработки события возникло ее одно событие, то запустить его на обработку. Какие элементы будут обрабатывать это событие, как именно, знают сами элементы, а не скрипт, который производит манипуляции с ними. А если возникает задание, например, добавить новый элемент в список обрабатываемых элементов, обычному разработчику нужно править скрипт, зачастую, вписывая новый элемент в десятки мест. SC-разработчику достаточно добавить новый элемент и указать, на какие события он будет реагировать и как; и, может, чуть изменить формат запуска события.