Через Жо

Пару недель назад на Хабре перевели статью одного из разработчиков Internet Explorer о том, почему innerHTML не работает с таблицами. Объяснение, почему оно не работает чётко показывает подход использованный в разработки IE. Подход «пиздец, ну и похуй».

Как это было и в прошлый раз с утечками памяти при работе с DOM, и на этот раз, вместо того, чтобы исправлять свой продукт, творцы из MS пишут статьи о том, каким путём проблему можно обойти. Путь, как и обычно, пролегает через жопу и кишечник.

Радуют объяснения из серии: «я мог проверить, что innerHTML у TBODY устанавливался во что-то, начинающееся с <tr>… Звучит достаточно просто, пока вы не начнёте учитывать все варианты. Вроде подающейся строки, например как <!— новые строки —><tr>…». То есть вместо того, чтобы забить на этот гипотетический вариант с комментарием, IE достигает универсальности одинаковой работы для всех вариантов. Универсальности из серии не работает ваще нигде.

, ,

json_encode сосёт

В новой версии PHP, как уже было сказано, пофиксено множество неприятных вещей. Среди них и баг за номером 42 090, опубликованный аж в июле 2007. Баг этот позволял грохнуть процесс посылкой непотребного JSON-запроса. Хотя, видимо, работало это только под Ubuntu (мне не на windows ни на freebsd воиспроизвести не удалось), всё же исправление данной ошибки, несомненно, радует.

А вот json_encode() продолжает огорчать. В документации к нему написано This function only works with UTF-8 encoded data. И правда, от любых других кодировок он просто отплёвывается. Но мне это до без разницы, неприятно то, что и с UTF-8, работает он через жопу.

Вызов json_encode("русский текст") выдаёт гомосятину вида \u0440\u0443\u0441\u0441\u043a… Какого хера? Зачем работая only with UTF, выдавая строку для JS, которая так же работает всегда only UTF, кодировать всё этими идиотскими мнемониками?

Мало того, что вывод превращается в кашу, в которой не разобраться визуально при отладке, так ещё вместо 2-х байт на символ, шлём 6. Вот вам и экономия трафика за счёт ajax’а.

Так что нужно или мириться с этим или извращаться самим на PHP, как это делают люди в комментариях к документации.

Если для каких-то высоких целей универсальности и сохранения совместимости это и необходимо, почему не ввести второй аргумент функции, типа, $mneNahuyNeNujnaSovmestimost? Впрочем второй аргумент там есть: [, int $options=0], как написано, это Bitmask consisting of PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP, PHP_JSON_HEX_APOS. Что означают все эти мракобесные константы не уточняется. Впрочем и уточнение тут не поможет — на любой вызов со вторым аргументом функция ругается json_encode() expects exactly 1 parameter, 2 given и Use of undefined constant PHP_JSON_HEX_QUOT.

Вобщем, ждём, когда adw0rd напишет новое расширение. :)

, , ,