s0rr0w

Насколько я понял, AJAX не нужно гонять при каждом изменении поля, а только при выходе из режима редактирования с подтверждением (не ESC)

Теперь можно пересказать все чуть более подробно, используя id в качестве имен, и привести какой-то сценарий и ожидаемый результат, используя в качестве примера "рыбные" данные. Я, если честно, не совсем сориентировался в задаче.

А можно я вопрос задам, это один из вариантов suggest'а?

Проблема не в JS, а в модных тенденциях и их плачевных последствиях при бездумном применении. Так что не JS виноват, а кривые руки.

Очень правильно сказал на одном из Я.субботников Макс Ширшин, что людей, которые намеренно отключают JS нужно изолировать от интернета как врагов прогресса.

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

Именно это и привело к "устойчивости" всей конструкции.

Создать клон текущего процесса.

Да.

Одаренные пользователи? Это не готовая библиотека, тут надо программировать.

Если сильно хочется убрать overflow: hidden, то можно это сделать так .plateBox { padding: 1px 0px; }

В старых да, на новой платформе поддержки уже нет Содержимонезависимая сборка. Не нужно постоянно переопределять свойства содержимого, оно само может иметь свои свойства и поведение, которое диктуется самими тегами. Например, я не переопределял свойства тега <p>, но даже если я это сделаю, поставив {margin: 10px 0px 0px; }, на общую конструкцию это никак не повлияет, а повлияет только на взаимоотношения тега <p> с другими элементами.

Я смотрю, ни у кого вопросов даже нет, ни обсуждения. Это значит, что или все всем понятно, или так никто ничего и не понял.

Когда вы сталкиваетесь с чем-то, что выходит за рамки вашего понимания, то вам это всегда кажется сложным. Как только вы разбираетесь с принципом работы, то все становится на свои места. SC не для начинающих, никогда им не был, никогда им не будет. Это все равно, что разбираться с xsd или xslt. Трудно первые два дня, потом сидишь и думаешь, вот это я тупой. Туториал вам расскажет только про то, что уже написано. Но не расскажет что нужно еще написать, чтобы это начало работать так, как вам надо, а не так как заложено разработчиками.

То управляй этим отдельно. Там класс .help убираешь, и заменяешь его на все, что душе угодно. Я не вижу ни одной причины, по которой контент должен не обрезаться, при вываливании его из этого блока. Ну добавь себе все что хочешь, блоки, статьи, таблички, все что угодно. Семантика содержимого .plateContent лежит на совести кодера.

Теперь мое решение http://jsfiddle.net/Q6H4K/ Что в нем особенного? 1. Я добавил "лишний" контейнер и перестал бороться с отступами у последнего или первого элемента. Элементы имеют отступы по умолчанию, за исключением h2. Инлайн текст не требует отдельных хаков. 2. Отсутствие поддержки :not() особо не скажется на визуальном форматировании. 3. Поток контента контроллируется по желанию, совершенно отдельно от общей обвязки. Проблема с ::before, но это чистейшей воды выпендреж, там можно заменить все на фоновую картинку и min-height. А решение лежит под носом, нужно всего лишь добавить один лишний контейнер.

Без first-child нельзя. Вернее можно, но решение будет очень сильно "плохим".

Ну что, больше желающих нет?

Производительность работы SC зависит только от кривизны рук писавшего запуск события. Обычно, область видимости распространения события довольно маленькая, до 20 нод. Используется еще и кеширование, поэтому самым медленным является первый запуск события, последующие работают в 4-5 раз быстрее. Тем, что гораздо проще, но при этом решается множество задач, а именно: 1. Сценариеподобный JS. Изменения дизайна или поведения отдельных элементов слабо затрагивает основной JS-код. Это значит, что при модификациях трудно допускать ошибки поведения, они перемещаются в сторону конечной имплементации. Событийной модели все равно, кто и как именно будет реагировать на события. 2. Это единый способ передачи данных между различными компонентами. 3. Позволяет строить слабосвязанную архитектуру, со всеми вытекающими последствиями 4. Переносимость JS кода может достигать 90% (переделки касаются только сценариев) 5. Полный контроль разработчика над происходящим. Разработчик может сам себе придумать и реализовать способ сбора произвольной json-структуры, при этом не написав ни строчки JS-кода. 6. Отсутствие изменения поведения библиотеки от версии к версии. Код SC и смежные библиотечные функции не подвергаются изменениям годами. Там нечего менять. Счастье промышленного разработчика.

Набрал ya.ru, нажал Enter, остался на этом же домене

Хаха, чуваки медленно, но уверенно идут к модели StateController'а... Я, пожалуй, еще годика два подожду, посмотрю на их эволюцию.

Можно легко обойтись без :last-child

Зачет, зачет

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

Извини, надо было сразу сказать, что БЭМ.