программирование

Пришло в голову попробовать использовать «картинку» (я продолжаю считать, что это видео) в формате MotionJPEG в качестве favicon. Ну забавно же — в favicon на сайте не примитивная анимация (через animated GIF или APNG), а что-то долгое, а то и бесконечное.

Да, понимаю, бесполезно и трафик жрёт, это just for lulz.

Смотрел в последних браузерах. IE9PP2 ничего не показал (он MJPEG не понимает), Opera 10.70a ждёт завершения скачивания и ничего не показывает, не дождётся, поток-то бесконечный, «Хром» 6.0.466.0 dev ничего не показал и не попытался, а вот FireFox 4.0b1 показывает стримминг на месте favicon.

Вот ещё пример бардака в браузерах — стало быть favicon выводится (почему?) не как обычная картинка. Ну, я понимаю, в DOM favicon выглядит совсем иначе, ну и что? Внедрённое изображение через тег OBJECT тоже выглядит в DOM иначе, но выводится наверняка тем же куском кода, который использует и тег IMG.

Появился проект «PHP для „Андроида“», поддержка PHP 5.3 интегрируется в т. н. «Android Scripting Environment».

На PHP для «Андроида» можно писать утилиты командной строки, фоновые процессы и GUI-программы, помимо PHP в Android Scripting Environment уже поддерживается выполнение программ на Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl и shell.

В данной версии PHP поддерживается всё API платформы — есть возможность управлять вибрацией, BT, камерой, Wi-Fi, определять географические координаты и так далее.

На сайте «SlideShare» появились (на русском языке) слайды с конференции «PHPconf» «Что нового с PHP 5.3» (на случай, если кто-то из интересующихся этим языком пропустил выход 5.3 и почитал changelog).

Я тут понял, что CSS Unit «__qem» вполне себе подходит на роль CSS-хака для браузеров на основе WebKit. Правда, мне неизвестно в какой версии эта единица измерения появилась. Подходит, правда не во всех случаях и с некоторыми оговорками.

Во-первых, лучше всего применять этот хак в режиме совместимости со стандартами, иначе Internet Explorer не обращает на хак никакого внимания и не отфильтровывается (впрочем, это обходимо, но неудобно).

Во-вторых, подходят свойства где есть что указать в численных единицах. Для того, чтобы хак сработал, нужно поставить на место числового параметра, например, «0__qem», а на место остальных — то, что необходимо. В некоторых случаях, есть возможность подправить потом и числовой параметр.

К примеру:

div {
    background: #000; /* фон будет чёрным везде, кроме… */
    background: 0__qem #fff; /* …WebKit, тут он будет белым */

    border: 0; /* бордюра не будет, кроме… */
    border: 0__qem solid black; border-width: 10px; /* …WebKit, тут будет чёрный толстый бордюр */

    position: relative; /* блок будет виден везде, кроме… */
    top: -100000_qem; /* …WebKit, тут его видно не будет */
}

Я попробовал поиграть с Media Queries, скомбинировать с «__qem» не удалось, но зато выяснилось, что браузеры и тут стандарт нарушают:

@media (color: 0!) {
     /* работает в «Хроме», по крайней мере, в 6-м */
}

@media (color: 0_) {
    /* работает в «Опере», по крайней мере, в 10.60 */

@media {
   /* работает в «Опере» 10.60, «Хроме» 6, не работае в FF4, IE8, IE9PP2 */
}
}

Судя по всему, эта нестандартная единица измерения не распознаётся в медиа-запросах, а жаль, получились бы хорошие хаки.

Случайно встретил в коде внутренних CSS WebKit странную единицу (CSS Unit) — «__qem»:

p {
    display: block;
    margin: 1.0__qem 0px
}

Спасибо, во внутренней «Ярушке» подсказали что это:

After lots of digging, I learned that the «__qem» unit used in Safari’s stylesheet stands for «quirky» em, and has to do with how margins behave in «quirks» mode, which is a topic for another day.

Удивительно. Причём, во всём интернете только один человек до этого докопался.

У меня в комментариях происходит интересное про проблемы cookie в «Опере». Проблемы наблюдаются в версиях 7.xx, 8.5x, 9.0x и 10.60. Возможно они есть и ещё в каких-то версиях.

Я как-то упоминал о том, что у «Яндекс.Паспорта» какие-то неопределённые трудности с выставлением cookie в «Опере», вот теперь становится понятно какие.

Спасибо Максиму Зотову, всё становится на свои места — некоторые версии «Оперы» принимают cookie с другого домена только со второго раза.

Не слишком ли вы увлеклись всякими тенями и уголками, ребята? Действительно ли нужно так часто выпускать новые версии без должного всестороннего тестирования? Имидж «Оперы» (сужу по комментариям на «Хабре») и без того почти такой же как у IE. Только IE ругают на неподдержку стандартов, а «Оперу» за своеобразное их трактование и баги.

Грустно это всё.

P.S. Подмывает создать тест, который проверял полноту поддержки старых, базовых вещей — поддержку Unicode, cookie, regexp и так далее.

В FireFox4 входит новый селектор — «:-moz-any». Позволяет задать на любом уровне несколько селекторов сразу. Например:

:-moz-any(ol, ul) li {
    list-style-type: none
}
a:-moz-any(:hover, :visited) {
    color: black;
}

В это связи легко получается CSS-хак для FireFox 4 и выше:

:-moz-any(x), .class_for_ff4 {
    color: red; /* стиль только для FF 4+ */
}

Только мне стало интересно как со скоростью JavaScript у флагманов современной мобильности, как оказалось, что добрые люди уже всё оттестировали.

На «Хабре» интересная статья о вреде алкоголя — «Происхождение тега <blink>»:

Субботним утром я направился в офис за чем угодно, но точно не за мигающим текстом. Он мигал на мониторе во всей своей красе и в браузере. Вы спросите, как такое случилось? Выяснилось, одному инженеру так понравилась моя идея, что выйдя заполночь из бара, он вернулся в офис и реализовал тег мигания. Поутру он всё еще был там, крайне гордый собой.

Надо бы узнать историю тега «marquee», возможно там тяжёлые наркотики виноваты.

Некоторые ребята почему-то подумали, что я предлагаю M-JPEG как универсальный формат видео в вебе. Ничего такого я не имел ввиду. Вероятно, я написал как-то слишком туманно.

Я лишь хотел обратить внимание на два факта:

• на бардак, когда формат видео не поддерживается тегом VIDEO ни в одном браузере, но поддерживается браузерами
• на то, что говорить «в браузерах нет единого формата видео» некорректно

И только.

С утра, складывая носковый пасьянс (не сошёлся, три (!!!) разных носка) — жена постирала чёрное, я задумался о формате M-JPEG. Если коротко, это формат видео, каждый кадр которого — JPEG. Очень простой формат, достаточно распространённый и его поддерживают основные браузеры — «Firefox», «Сафари», «Хром», «Опера», не поддерживает только Internet Explorer (даже девятый).

Таким образом, вопреки всем разговорам, у нас уже есть единый потоковый видеоформат, de facto, причём есть давно. Правда, плохенький (напоминаю — каждый кадр целый JPEG) и проигрываемый немного по-разному (обредший нового адепта «Хром», тормозит меньше всех). Впрочем, чтобы как-то обелить формат, у него есть и достоинства — каждый стоп-кадр у него довольно качественный, потому M-JPEG любят в камерах охраны.

Бардак заключается в том, что тег VIDEO не поддерживает формат Motion JPEG ни в одном из браузеров. Это многое говорит о том как производители браузеров определяют вектор развития их детища. В погоне за модой забывают наводить порядок и править баги (красный круглый камень в дырочкой в чей-то огород).

Воспроизводится M-JPEG через тег IMG, я даже небольшой пример накидал за 15 минут (нажмите круглую блямбу справа внизу картинки для воспроизведения).

При помощи тега CANVAS, M-JPEG и метода «stop» у окна можно даже сделать плеер, плохой, но работоспособный. Я попробовал, но результат мне не понравился. В частности, потому что тег IMG не умеет управлять видеопотоком, стоп-кадр нужно делать при помощи CANVAS, а сделать его можно только после остановки видеопотока (метод «stop» у окна нам в этом поможет) и плеер между остановкой видео и появлением стоп-кадра секунду не показывает ничего.

Можно, кстати, вспоминить, что Internet Explorer с какой-то бородатой версии поддерживает DYNSRC у тега IMG, причём там-то этот тег имеет богатое API для управления видео, в котором есть всё, что сделать полноценный плеер.

Ещё более кстати, что этот плеер будет поддерживать видео в формате AVI и кодеки установленные в системе, так что если у вас в системе есть кодек для M-JPEG, можно просто гнать видео в этом контейнере, IE его должен понять. То есть, можно и Internet Explorer обучить понимать Motion JPEG.

Одной из бесполезных конструкций языка JavaScript называют «with». Неспроста, эта конструкция непрозрачна и потенциально может создать непростые проблемы. Небольшой код:

with (MyObject) {
    width = '100px';
    height = '200px';
    display = 'block';
}

Что будет, если свойства с таким именем не найдётся? Код заменит значения переменных width/height/display или же создаст их, если их ещё не было. Что приведёт к проблемам, если мы в связанном коде где-то используем такие имена.

С языком VBScript я знаком с тех пор как программировал, используя технологию ASP. В дальнейшем, я иногда использовал его, чтобы программировать что-то для Internet Explorer, всё-таки некоторые вещи для этого браузера было проще делать в нём.

Этот язык я, в общем-то, не люблю (в отличие от JavaScript), но вот конструкция «With» устроена в нём разумнее:

With MyObject
    .width = "100px"
    .height = "200px"
    .display = "block"
End With

Заметили точки впереди? Они говорят о том, что используются не просто переменные, а свойства (ну или методы) объекта, указанного в «With». Вот так просто решается куча проблем.

Прощай, «Опера», мне было хорошо с тебой, но это невыносимо. С версии 10.50 ты обрастаешь багами, как баржа ракушками. Сегодня я увидел, что на твоём FTP лежит релиз версии 10.60, а в нём три критичных для меня бага, два из которых делают жизнь в нашем интранете для меня труднее. Я терпел, сколько мог, но больше не могу.

Научите меня пользоваться «Хромом», ещё лучше — «Хромиумом», он, говорят, быстрее развивается, что немаловажно для молодого браузера. Что ставить? Откуда скачать уже собранные версии «Хромиума»?

Помимо GIF, JPEG, PNG и SVG в браузерах есть ещё один «общий» формат графики — XBM. Не сказать чтобы сильно полезный, скорее забавный. Формат текстовый и очень простой, как раз его использует Wolf5k для отображения графики.

Несколько лет назад его поддержку прекратил браузер IE, с версии IE6.0SP1 XBM больше не поддерживается. Причина проста — IE падал, если подсунуть ему неправильно сформированную картинку. Поэтому поддержку формата просто отключили (сделали ключ в реестре («BlockXBM»), если очень хочется, поддержку можно вернуть). В общем-то, правильно, формат совершенно гиковский и его использование большая редкость (хотя и встречается).

И вот сегодня я, поставив Firefox 4.0b2pre, увидел, что в нём нет поддержки XBM. Стал разбираться. Оказывается его поддержку выключили в версии 3.6:

It doesn’t seem like anyone uses XBMs on the web these days (microsoft dropped support for them in ie6), and we no longer use them anyone in the platform. Each additional image decoder makes it more time consuming to maintain imagelib, because changes have to be replicated. Thus, unless somebody has a reasoned opinion to the contrary, I’ll remove XBM support in a week or two.

Увы. Из исходников выкинули совсем, никакого ключа в реестре.

Решение проблемы скруглённых уголков через VML есть в статье Льва Солнцева «Кроссбраузерные закруглённые уголки» (без JavaScript). Проблема заключается в следующем:

В VML есть предопределённая фигура: прямоугольник с закруглёнными углами roundrect. […] Но у этой фигуры есть один значительный недостаток: радиус кривизны задаётся через отношение к большей стороне, что делает результат непредсказуемым и неподходящим для многих случаев.

То есть, при одинаковом параметре закругления блоков разного размера, радиус кривизны будет различаться.

Поиграл немного с Google Native Client — это плагин для браузера (поддерживаются Firefox, «Опера», «Сафари» и «Хром» и платформы Windows, Mac и Linux на x86, x86-64 и ARM).

Это плагин, который умеет исполнять скомпилированный бинарный (!) код в браузере. В каком-то смысле это напоминает ActiveX. Вы пишете бинарный код, компилируете его в специальной версии gcc, а потом просто встраиваете в браузер тегом EMBED.

Меня интересовало как тут соблюдается безопасность. Коду многое запрещено (по сути, всё, что разрешено — это эффективное использование процессорного времени, за остальным нужно обращаться в браузер через NPAPI или SRPC (Simple RPC)), но разработчики много говорят о том, что допускаются ассемблерные вставки.

Как так?

Ларчик, как оказывается, открывается просто и достаточно остроумно. Во-первых, разработчику запрещается использовать некоторые конструкции, например INT (вызов прерывания) и некоторые другие. Во-вторых, команды переходов модифицированы и это самое интересное.

Не знаю как там в процессорах ARM, а в x86 команды могут иметь разную длину, какая-нибудь «PUSH AX» занимает байт, «MOV AL,41» — два, « MOV AX,[BP+8]» — три и так далее. Если сделать переход не на первый байт команды (а, например, на второй байт команды «MOV AL, 41»), то окажется, что оставшаяся последовательность (возможно с байтами, которые идут дальше) тоже что-то означает (в случае «MOV AL, 41» второй байт будет «41», это команда «INC CX»).

Это даёт возможность замаскировать внутри команды любую запрещённую команду и выполнить её, сделав переход не на первый байт. Как Google Native Client защищает нас от этого? Очень просто.

В Ассемблере есть специальная команда — «NOP» (в x86 занимает один байт, её код — «90»), она не делает ничего. Все команды вашей программы выравниваются до 16 байт этой командой. То есть «MOV AL,41» будет дополнена 14-ю командами «NOP», а все переходы разрешаются только на границу этих 16-ти байт. Для этого у адреса перехода всегда отрезаются несколько младших бит.

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

Интересно, что код, контролирующий безопасность и реализующий SRPC, получился очень небольшой, в ролике на YouTube разработчик говорит то о 6000 строк, то о 6000 байт. В любом случае, то и другое — немного. Там же (в ролике) показывали интерпретатор Ruby, работающий в браузере. Это интересно, но не более, интереснее то, что код на Си (или там C++, неважно) пришлось менять очень мало, чтобы перекомпилировать его в Google Native Code.

Мне кажется, это интересный проект.

Забавная была игрушка «Wolf5K». Это игра на JavaScript, занимающая пять килобайт (!). Был такой конкурс когда-то — «The 5K», цель — уместить что-нибудь толковое в 5 килобайт.

Ребята произвели фурор тогда, они уместили в этот размер небольшую псевдотрёхмерную бродилку. Никаких CANVAS! Хитрость в том, что вся графика (кроме кровищи) делается в формате XBM и передаётся тегу IMG через схему «javascript». Игрушка работала в IE5, IE6, Mozilla 1.1+ и Netscape 4.77 для Мака.

Формат XBM — это текстовый формат чёрно-белых картинок (я даже когда-то делал библиотеку для PHP Image::XBM). Его удалили из IE в SP2, работает ли это до сих пор в Gecko-браузерах я не знаю (у меня сейчас не установлен FF, а ставить лень), а «Опера» не читает графику через схему «javascript», так как никогда не делает попыток угадать контент по содержанию. Только по MIME-типу.

В общем, захотелось мне почему-то вспомнить эту игрушку, а она у меня не работает. Ну, делов-то. Заменить схему «javascript» на чуть доработанную «data». Вот патч, нужно открыть окно игры, скопировать его в строку браузера и нажать «Enter»:

javascript:void(eval(X.toString().replace(/"j.*?;"/, '"data:image/x-xbitmap," + encodeURI(im)')))

В IE по-прежнему работать не будет (в нём нет XBM), в «Хроме» тоже не должно, в «Опере» — заработает. Если у кого-нибудь установлено что-то ещё, попробуйте и скажите получилось ли.

Добавлено утром: читатели сообщают, что в «Сафари» тоже работает.

Из блога IEBlog:

var len = [1,2,3,].length; 
alert(len); //should be 3, IE8 says 4

В IE9 поправили застарелый баг — Internet Explorer добавляет ещё один элемент в массив, если в конце перечисления элементов массива есть запятая. На этом основан самый короткий способ проверки на IE через JavaScript. По стандарту последняя запятая игнорируется. IE9 теперь следует стандарту.

Не будет работать и проверка через «\v» (цитата из того же блога):

alert("\v"==="v");//IE8 said true, should be false 
alert("\v"==="\u000b"); 
    //IE8 said false, should be true

В общем, полагаться на хаки в таких проверках будет нельзя. Думаю, единственный надёжным способом будет условная компиляция:

if (/*@cc_on!@*/0) {
    // IE
}

P.S. А вот найденную мной… особенность метода split в IE9 так и не поправили.

Ну что, AMD действительно тогда проговорилась, никакой ошибки нет — в IE9 будет CANVAS. Только что появился Internet Explorer 9 Platform Preview 3 и там есть CANVAS.

Должен сказать, скорость очень хорошая. Реализовано пока не всё (это всё-таки даже не альфа), но для работы многих демок и игрушек хватает. Правда на синтетических тестах результаты противоречивые. Я сравнивал с последней сборкой «Оперы» 10.60, где-то IE9 впереди, где-то «Опера» сильно обгоняет.

Кажется, с применением полупрозрачности (и тени) производительность IE9PP3 пока резко падает.

Из других новостей: AUDIO, VIDEO, CANVAS с аппаратным ускорением, увеличена производительность и улучшена его поддержка JavaScript, поддержка WOFF (формат шрифтов), ACID3 — 83%, HTML5 test — 84/300 (предыдущий результат — 32).

Unicode со «школотой» по-прежнему рисует квадратиками.

На «Хабре» появилось сравнение кодеков Theora, H.264 и VP8, основной вывод:

Формат VP8 вполне подходит для веба. Он намного лучше Ogg Theora и сравним с H.264 по параметру размер/качество. Вопросы о патентной чистоте и скорости декодирования остаются пока открытыми. Получит ли формат распространение — это вопрос скорее коммерческого и политического успеха, нежели технического.

H.264 остаётся лидером, а Theora, похоже, безнадёжно отстала от конкурентов.