s0rr0w

Какие интересные предрассудки у людей бывают.. Если по-хорошему, то для данной задачи даже JS не нужен

Первый рабочий

О коде cypler'а

Код явно с ошибками

Что-то мне подсказывает, что всю спеку в вики можно сделать.... А давайте так и поступим.

var i = 4; Создается глобальная переменная с именем i var shooter = function me() {} Создается переменная shooter, которая будет ссылаться на именованную функцию me shooter.i = i; Функции me (по сслыке через переменную shooter) будет добавлено свойство i, ккоторому будет присвоено значение глобальной переменной i shooter(); Вызов функции me по ссылке через переменную shooter alert( me.i ); Вызов функции alert и передача ей в качестве параметра свойства i функции me

Репозиторий https://github.com/s.../guidelines.git Для работы необходимо зарегистрироваться на GitHub, и написать мне ник. Рабочая группа s0rr0w SelenIT alexriz amelice Great Rash nerv Catherine Kelin Николя223 Svatov wwt Процесс работы Процесс работы будет следующим: Спецификация будет представлять собой html-файл, который могут править участники рабочей группы и отправлять в master-репозиторий. Структура документа будет максимально приближена к той, что используется на w3c. Далее, выбираем раздел или какое-то определенное свойство, обсуждаем все возможные варианты использования (скайп или прямо тут), рисуем примеры и различные варианты использования. При необходимости, вносим изменения в спецификацию. Повторяем этот шаг несколько раз. После финализации работы, нужно будет привести в порядок все изображения и перевести на английский. Финальный шаг - представление проекта рабочей группе w3c

Вот и рабочая группа подоспела! Завтра начинаю работу по организации процесса.

Анализировать и критиковать. Нужно идеи проверять на их жизнеспособность, понятливость, удобстве использования 2. Я тоже 3. Не проблема 4. Да 5. Супер, вместе справимся, я думаю 6. Это не сложно, зарегаться в w3c mailing list - пять минут дела. Мне понадобится поддержка, чтобы создать массовку

Это только мааааленькая часть от того, что действительно могут направляющие. Но, похоже, пора доставать из шухлядки свои наработки, да начинать точить камень нанаово. Господа, предлагаю следующий план 1. Собрать рабочую группу 2. Открыть проект на том же гитхабе 3. Написать спеку на русском 4. Сделать множество примеров 5. Перевести на английский 6. Закинуть в w3c Кто со мной? http://www.w3.org/TR/2013/WD-css3-grid-layout-20130402/#repeat-notation Да, в целом, можно сказать, что идея дала всходы.

Он не то, чтобы закостенел. Просто люди не хотят смотреть дальше своего носа. Никому не интересно думать над проблемой и искать способы ее решения Текущую спецификацию пишут программисты. Не веб-разработчики. Поэтому судят все только со своей колокольни - легко или тяжело реализовать. Никому не интересно, что их высер (а по другому тяжело назвать некоторые идеи) не имеет вообще связи с реальностью, что он просто не жизнеспособен еще на моменте идеи. Взять те же гриды. Это просто ужас, они повторяют таблицы и flex-box'ы. Нахрена они такие красивые нужны?

Эволюция схем позиционирования была примерно такой Вначале был просто поток. Потом в нем появились вкрапления по типу инлайн-блоков, флоатов, инлан-таблиц и так далее. Управление потоком неразрывно связано с позиционированием. Если вы переставляете ноду куда-то в другое место по дереву, это может отражаться на множестве ее характеристик, например она станет визульно меньше по размеру, так как слева стоит float, который нужно обтекать. Переставление ячейки таблицы меняет ее положение. И так далее. Потом появились "проблемы", и разработчики стандартов понемногу начали склоняться к статическому представлению контента на странице. Вот есть блок, он вот тут гвоздиком прибит и это хорошо. Сейчас все больше появляется мест в стандарте, когда физическое местоположение ноды в дереве DOM перестает влиять на отображение. И если для управления местоположением элемента в дом-дереве есть куча методов, то для аналогичного управления, динамически через CSS, потребуется работать с ужасным интерфейсом - style. Логично предположить, что наиболее выгодным для разработчика будет тот метод позиционирования, который позволяет комбинировать силу DOM-методов и потоковое управление контентом. Добавляем сюда требования к адаптивности, ведь мы не хотим создавать множество медиакверей для разных устройств, потому что это банально дорого. Кто работал с графическими редакторами, тот знает, что там используются направляющие (guidelines), которые помогают в выравнивании контента. И есть такой эффект как прилипание к направляющей, когда край какого-то объекта подносится близко к линии. Берем аналогичное поведение для страницы. Мы разлиновываем контейнеры направляющими и рассказываем блокам, как они должны прилипать к определенным линиям. Если размеры не позволяют прилипнуть, мы можем перескочить к следующей направляющей. Прилипать можно по разному количеству сторон. Если разлиновать некий бокс вертикальными и горизонтальными направляющими, а потом заставить ячейки прилипнуть ко всем 4-м сторонам, то получим таблицу. Если взять только один элемент и прикрепить его к какой-то одной стороне, то получится флоат. Гриды и флексбоксы делаются путем аналогичного прилипания. Лайнбоксы ни что иное как гайдлайны для инлайн-контента. Выравнивание текста = прилипание к определенному гайдлайну (центрирование тоже можно сделать путем прилипания разных точек, т.е. бокс описывается не 4-мя а 8-ю точками) Только что я описал базовый механизм позиционирования почти всего в CSS

Спасибо, господа, за теплые слова Я эту идею почти до совершенства довел, даже через гайдлайны все остальные элементы спозиционировал, начиная от таблиц, заканчивая флоатами. Никому в w3c это не интересно. Оставлю-ка я это сдесь. Первые потуги http://lists.w3.org/...10Sep/0097.html http://lists.w3.org/...10Sep/0243.html http://lists.w3.org/...10Sep/0280.html Вторые http://lists.w3.org/...12Feb/1172.html Особенно мне нравятся ответы Гуглогуру Таба Эткинса http://lists.w3.org/...12Feb/1344.html Читаем между строк: Я не хочу разбираться во всем этом, лучше оставить все как есть, так мне проще

ID должен быть уникальным в документе. Поэтому нужно заменить сначала селектор на class, а потом уже each применять $(".orderFormSubmiter").each( function(){ if ($(this).length) {.... Не ручаюсь за правильность кода, я в jQuery олух

Нода = тег

Нормальные люди с XML через DocumentFragment и DOM работают...

С точки зрения экономиста на спичках, конечно же можно использовать пайп. Но пайп тебе дает просто безымянный список. Как только возникнет задача мапить параметры, пайп начнет проигрывать, и придется переделывать все. Json имеет, кроме прочего, хоть примитивную, но валидацию структуры передаваемых данных. Да, сложность реализации с json выше, но зато расширяемость и универсализация несравнимо лучше Та то братаны мои...

var var1 =[]; - укороченная запись создания пустого массива. Равнозначно var var1 = new Array(); var var2 = {}; - аналогично, только для объекта. Равнозначно var var2 = new Object(); $('#question')[0] - прямое обращение к ноде, иначе, без [0] будет обращение к объекту jQuery

json-сериализацию

А что делать, если в строке символ | попадется?

Там нет открытого проекта, в нем используется уже откомпилированный swf-файл. Но подгружаемые им .as файлы можно вполне менять. Компилировать ничего не надо, никакие программы кроме текстового редактора не нужны

Эх, я пропустил столь замечательное событие. Но, лучше поздно, чем иногда. С днемваренья тебя! Пусть все твои мечты сбываются, но их количество никогда не уменьшается!

Там где Tool settings, вы можете выбрать путь не просто php, а полный к исполняемому файлу php?

Выложил свои презентации в первом посте

Для кого? Для опенсорс-проектов, где код коммитят по делу и без, да, очень сильно важно не сливать весь треш в кучу. Но когда тебе нужно иметь одну точку для контроля доступов, тут децентрализация не помощник