rash

Можно без кавычек. Обратите внимание, что используется эквивалентность, а не равенство (===) и не используется typeof (но это сложно не заметить) Также эта функция может дать сбой, если где-то в скрипте определена переменная с именем undefined (обычно так не делают, но если используется много скриптов от разных авторов, стоит быть осторожнее).

Тернарный оператор — это выражение «? :» — там первое выражение, которое вы проверяете, уже возвращает нужный результат, не надо явно возвращать true или false. Function Expression — это в вашем случае объявление функции с явным присваиванием ее переменной (var cv = function…), Function Declaration — объявление сразу именованной функции (function cv(v) {…}) — в этом случае разницы не должно быть никакой для вас, а запись короче. Ну и насчет ошибки (тут не могу утверждать со 100% уверенностью, что правильно понимаю работу интерпретатора, скорее моя версия) — при вызове функции cv(notexists) произойдет обращение к переменной notexists, чтобы передать ее в виде параметра, и если ее не существует — будет ошибка. До того, как внутри функции выполнится проверка.

непонятно, что такое cv (как читать, что значит). Не надо так уж сильно экономить буквы, почему бы не function exists(x) { return typeof x != 'undefined';}ну или саму функцию можно назвать 'defined', дело вкуса. А если вы уж так сильно экономите байты (хотя gzip на сервере делает это занятие почти бессмысленным), то и вашу cv можно сократить: function cv(v) { return typeof v != 'undefined';}Тернарный оператор там не нужен, да и зачем использовать Function Expression в этом случае? Тут Function Declaration, насколько я вижу, проблем не принесет, а запись короче. Ну и надо заметить, что в момент вызова несуществующая переменная, похоже, приведет к ошибке. Так можно отследить только неопределенную переменную.

Надо отметить, что второй вариант определит как несуществующую также переменную, значение которой — пустая строка, null, 0, false, NaN. А это могут быть уже присвоенные и нужные значения. Первый вариант (с typeof) привык использовать и я, потому что значение undefined может быть переопределено, и простым сравнением тут не обойтись, если не уделить этому внимание явно. А проверка типа должна дать верный результат в любом случае.

Асинхронность, и, собственно, единый язык для фронтенда и бекенда? А также обилие готовых модулей (правда как именно с модулями или их аналогами в php я даже не в курсе)

Нет, обычно только «диффы», то есть на клавишах, где украинская буква не соответствует русской, нанесена дополнительно еще и украинская. Но по большей части раскладки совпадают.

да

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

Регулярки для js, особенно если не просто потестить, а еще и поправить, смотрю в https://addons.mozilla.org/en-US/firefox/addon/rext/

Да, удивительная моя невнимательность Даже обидно. Хотя у меня регулярно случается...

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

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

нет, там все верно. Строка 881, как я понимаю, вообще не должна попасть в результаты (может я неправильно понял условие, но двойка внутри тега быть должна, просто не в начале и не в конце содержимого). И строка dsnkjds<df2dsjkds тоже попадает правильно — двойка не стоит непосредственно перед символом <, поэтому совпадение есть.

Да уже понятно, что скорее всего php, но, блин, почему в нем работает иначе...

Да это не мой вариант, просто мне он понравился краткостью. И с точки зрения логики работы регулярок должен делать как раз то, что надо. Просто я протестировал его сразу на js, а оказывается вот оно как...

Тьфу, это для php. Не знаю, какие там особенности, но в js отрабатывает как надо, последняя группа матчится полностью. Хотя даже странно, использованы только базовые возможности, что тут может пойти не так... UPD. Да, в php последняя группа матчится неверно. Забавно...

То есть вам по сути не аккордеон нужен, а набор спойлеров? Чтобы каждый последующий клик менял состояние блока на закрытое/открытое? С произвольной разметкой не получится, но если можно написать свою разметку — то возможно. Но это только в порядке упражнения для «поизвращаться». В продакшен я бы такое не пускал. Если вы можете подправить разметку — используйте предназначенный для этого аккордеон, найдите готовый. Если в разметку вмешиваться нельзя, то она, скорее всего, и для css-аккордеона не подойдет.

nrev, изящно!

Потому что для выравнивания по центру стиль должен быть задан у элемента с блочным отображением. Для строчного этот стиль не имеет смысла. Достаточно будет добавить еще и display: block;

Почти наугад, «пальцем в небо», а если запускать эту анимацию по нулевому таймауту?

Я вот давно хочу выучить, не так для веба, как вообще. Для автоматизации, например. Да и язык красивый. Так что если соберетесь учить — лишним не будет. Хоть и настоятельно рекомендовать его тоже не буду — есть альтернативы приблизительно того же уровня.

Задача — что-то типа кастомных контролов. Соответственно, на странице их может встретиться довольно много (заранее неизвестно), и каждый должен вести себя самостоятельно. Все данные, которые от него могут понадобиться другим частям скрипта будут доступны из DOM-представления (все равно все делается на базе стандартных контролов, просто вокруг них навешивается дополнительная функциональность и логика), остаются те же value, onchange, onblur и добавляются некоторые jquery-события. Совсем по-хорошему, наверное, надо плагин написать для этого. Но сейчас не планирую.

Ну вот и я пришел к такому же выводу, просто, вероятно, когда-то бегло читал документацию по .on, и на data не обратил внимания, так и жил в уверенности, что такой возможности нет

Штука в том, что данных немного, но они должны быть назависимыми для каждого экземпляра. Local storage ни к чему, они нужны только на время существования страницы и только на этой странице. В общих чертах — «поведение» каждого блока требует хранения его состояния. И глобальный объект тоже ни к чему — они имеют смысл только внутри самого блока, к ним не нужен доступ извне. Но каждый блок должен вести себя независимо, то есть хранить свое собственное состояние отдельно от других.

Цикл не нужен, просто так получается удобнее, и опять же за счет замыкания на общего родителя, которому делегирую обработчики, проще сохранять данные для каждого экземпляра отдельно (а это и нужно). В вашем случае data получается общей для всех экземпляров. Конечно, данные можно привязать к DOM-элементу через .data, но мне не хочется этого делать уже только потому, что этого можно не делать, воспользовавшись обычной переменной. Или у сохранения в DOM есть какие-то преимущества, которые я упускаю? Пока мне кажется, что это имеет смысл делать, если к данным должен быть доступ из разных блоков или частей документа, которые не смогут воспользоваться общей переменной. Впрочем, ваш подход можно попробовать адаптировать к моему второму варианту. Что-то я упустил из виду, что при назначении обработчика можно данные передавать через event.data. Код немного увеличится, но по памяти должно получиться экономичнее все равно. Свежий взгляд помогает