1. Да, я понимаю. собственно вопрос стоио бы разбить на две части: mysql_real_escape_string vs mysql_escape_string и mysql_real_escape_string vs someone_own_escape. В первым случае, как вы думаете, разница будет только в обработке многобайтовых строк?
2. Скорее всего. Собственно, я предпочитаю использовать mysql_real_escape_string, но почему-то каждый, кто использует мою библиотеку, старается вместо вызова соответствующей функции использовать вышеприведённый код, ссылаясь на необходимость действующего подключения для mysql_real_escape_string. По идее, т.к. в javascript строки в юникода, то всё должно быть ОК.
3. Вы правы, уже вижу отсутствие обработки _, %, \t, \b и \Z. Но это дело наживное, можно дополнить для полного соответствия спецификации.
В списке блогом есть один уровень каталогизации. Так что без изменения основного кода, думаю было бы хорошо иметь возможность просматривать топики из определённой категории.
Имхо, такой CSS пишется, как вы сказали, «неспециалистом» за час максимум. Всего-то проставить понравившиеся отступы и размеры шрифтов. Всё остальное — шелуха, которая может и не понадобиться, либо подгон дизайна под существующий сайт.
Да лажают они, что тут сказать :-) XenForo не смотрел ещё, но по функционалу ничего нового, а как можно испортить современный код IPS хорошо показали на примере тройки. Так что не всё так хорошо, как мне кажется.
Если обратить внимание на мелочи, то становится ясно, что речь не про PHP, а про JavaScript.
Так что проблема многобайтовости должна отпасть сама собой, так как UTF8 поддерживается «из коробки» и без проблем.