Тег HYPE (Netscape HYPE tag sound)

MacOS 9 (88.80КиБ) Пятнадцать лет назад, ковыряя исходники браузера «Нетскейп», я наткнулся, в частности, на тег HYPE — в интернете того времени писали, что он воспроизводит какой-то звук, но только в старых версиях браузера и не под «Виндоуз». «Мака» у меня тогда не было, как и доступа к «Линуксу» с графическим интерфейсом, поэтому безуспешно поискав по интернету подробности, я исследование забросил.

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

Но времена же изменились! Теперь у нас есть виртуализация, образы виртуальных машин и быстрый интернет! Где-то полчаса ушло на поиск и скачивание второй версии «Нетскейпа», готовой виртуалки с девятой «МакОСью», установку всего найденного, разбирательство как всё запускается. Но при вводе заветного тега меня ждало препятствие, к счастью, устранимое — виртуалка заявила, что у меня нехватает какой-то Sound Machine и, вместо проигрывания звука, предложила скачать звуковой файл.

Файл оказался в формате .snd, который нормально открылся и проигрался уже в современном «Маке». Его содержимое — фраза «What is global hypermedia?» (из документа NCSA Mosaic Demo 1993 года, как объясняется на одной из страниц в интернете). Я сконвертировал его в обычный МП3 и, если ваш браузер достаточно современный, можете послушать как звучит тот самый секретный тег:


Кстати, жаль, что я не догадался проиграть его на оригинальном «Макинтоше» в музее Эпл, в Москве. Если представиться случай, обязательно попробую!
2 комментария
28 октября 2015 09:08

IE9 и таблицы

IE9 и таблица (18.31КиБ) В продукте, которым я занимаюсь, минимальная версия Эксплорера, которую я решил поддерживать — девятая. В будущем я хочу поднять это требование до десятой, а пока приходится жить с тем, что есть — клиенты не готовы к резким переменам и я их понимаю.

Наткнулись на странную проблему в этой версии Эксплорера — некоторые таблицы выглядят как на снимке выше — ячейки в строках иногда выпирают вправо безо всякой видимой причины.

Дело оказалось в пробелах между ячейками — верстальщик отформатировал шаблон, чтобы он лучше читался, и все браузеры всё показали правильно, один девятый Эксплорер сошёл с ума. Лечится проблема запросто — либо убираем форматирование в шаблоне, либо убираем его прямо в браузере.

Я выбрал второй путь. Пусть лучше шаблон выглядит читаемо, а костыль для девятого Эксплорера всегда можно будет убрать лёгким движением руки. Выглядит он вот так, кстати (используется jQuery, само собой):
$("table tr").contents().filter(function() {
    return this.nodeType == 3;
}).remove();
16 комментариев
5 июня 2014 09:09

Свёртка в вебе

Я как-то пропустил момент, когда фильтры SVG стало можно накладывать на обычный тег IMG, а не на изображения внутри SVG же. Любопытные эффекты можно делать, например, можно наложить свёртку для выделения краёв и это будет работать:
<style>
    .edge {
        -webkit-filter: url(#edge);
        filter: url(#edge);
    }
</style>

<svg style="width: 0; height: 0">
<filter id="edge">
<feConvolveMatrix kernelMatrix="-1 -1 -1 -1  9  -1 -1  -1  -1" />
</filter>
</svg>

<image src="sample.jpg" class="edge">
Магические числа в матрице — специальное ядро.

Впрочем, и раньше можно было внедрить в ХТМЛ СВГ-картинку и наложить сверху фильтр, ничего особенного, но мороки чуть больше. При желании этот фильтр можно унести прямо в ЦСС при помощи data URI, но тогда он продублируется два раза — для префиксной и безпрефиксной формы (несмотря на уверения «Кэнайюз», «Хром» и «Сафари» отказались работать без префикса).

С таким возможностями, немудрено, что онлайновых «фотошопов» развелось, как грязи. Немного помучавшись с консолью, можно найти способ как поменять матрицу и это тоже будет работать! Например, вот так меняется число по центру (где у меня в примере девятка записана):
var arr = document.getElementById('edge').childNodes;

for (var i = 0; i < arr.length; i++) {
    if (arr[i].kernelMatrix) {
        arr[i].kernelMatrix.baseVal.getItem(4).value = newvalue;
        break;
    }
}
Осталось только соединить этот код с «крутилкой» и готов онлайн-фильтр «выделение краёв».
10 комментариев
26 мая 2014 06:41

Ленивая загрузка в ИЕ11

В IE11 интересную штуку сделали — ленивую загрузку. Можно пометить картинку (включая внедрённые тегом SVG), теги для воспроизведения видео и аудио, скрипты и многое другое специальным атрибутом lazyload, который означает «начать загружать, когда загрузится всё важное».

Иногда может быть удобно, для оптимизации скорости загрузки страницы, попросить браузер не загружать пока что-то объёмное. Я, например, в одном из наших проектов поставил этот атрибут аватарам пользователей. Пример использования:
<img src="avatar-3132.png" width="200" height="200" lazyload="1">
Можно добавить этот атрибут к банерам (на что мало кто согласится), большим графическим оформительским элементам (чтобы пользователь быстрее начал читать статью), фоновой музыке (правда она редко бывает вообще уместна) и т.п.
9 комментариев
28 декабря 2013 12:14

SVG с fallback на не векторные форматы

Нравятся мне такие вещи. Алексей Тен из Яндекса придумал очень изящный способ внедрения СВГ в код с возвратом к растровому формату, если браузер не поддерживает СВГ:
<svg width="96" height="96">
    <image xlink:href="svg.svg" src="svg.png" width="96" height="96"/>
</svg>
Принцип виден из кода, я думаю, но я всё же расшифрую. Если браузеры поддерживают внедрение СВГ в ХТМЛ, то почти весь выше приведённый код будет для них значимым: кроме атрибута «src», его у тега СВГешного image не бывает и он будет отброшен. Соответственно, картинка загрузится из файла svg.svg.

Если же браузер СВГ в таком виде не понимает, то будет отброшен тег svg и атрибут «xlink:href», а тег image будет преобразован в img — это старая особенность браузеров, которой я тщетно пытался придумать применение. В этом случае будет загружен svg.png.

Я уже на сайте в одном месте использую этот трюк.
4 комментария
3 сентября 2013 07:55

SVG-спрайты

Вчера ночью, эксперементируя с различными способами внедрения картинок в ХТМЛ, я понял, что уже все браузеры (кроме «Оперы Мини»), понимают СВГ прямо в коде страницы. А это значит, можно отказаться от CSS-спрайтов в пользу того, что можно назвать «SVG-спрайтами»: SVG-спрайты (162.51КиБ) Принцип, в общем-то, тот же: большая картинка, из которой показывается фрагмент, только фрагмент задаётся не через ЦСС, а прямо в ХТМЛе.

Думаю, всем понятен код: в теге svg задаются размеры кусочка спрайта, в image обязательно нужно указать полные размеры картинки (для Ретины можно указать их в два раза меньше, если спрайт подготовлен к этому типу экранов), при помощи параметров x и y позиционируем в каком именно месте спрайта расположена наша картинка.

В комментариях спрашивают зачём это всё надо, чем это лучшее спрайтов в ЦСС.

Ну, во-первых, это семантичнее. Понимаю, для многих это не аргумент, поэтому у меня есть два других. Итак, во-вторых, браузеры стараются фоновые картинки (в спрайтах ЦСС используются именно они) грузить в последнюю очередь, это логично — как правило, они менее важны. В-третьих, фоновые картинки часто не отображаются при печати (у некоторых браузеров в настройках печати есть возможность вывести на печать с фоном, но по-умолчанию это отключено).
14 комментариев
14 июня 2013 07:56

Обнаружение Ретины

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

Наиболее животрепещущий вопрос — подготовка изображений для Ретины.

Напомню, что Ретина — технология Эпл, ставшая уже нарицательной, заключающаяся в примерении экранов высокого разрешения (например, на моём ноуте это 2560×1600) с отображением на нём обычной графики так, как бы это выглядело на экранах вдвое низкого разрешения. При этом шрифт смотрится просто великолепно, как на бумаге, а вот с картинками беда.

В вебе бо́льшая часть графики выглядит не очень (хотя масса сайтов уже подготовилась). Для того, чтобы стало хорошо, все изображения надо готовить вдвое большего размера, при этом указывая для них в коде вдвое меньший размер, тогда проявляется вся мощь Ретины — будет видно самые мелкие детали изображения и пропадёт размытие.

Пока ещё не у всех Ретины, хочется, чтобы клиенты, у которых её нет, не грузили лишнего. К сожалению, загвоздка в том, что браузеры пока не научились сообщать серверу, что мы имеем дело с таким (пока) необычным экраном и есть только клиенские способы выяснить это.

Появилось уже несколько библиотек, которые на стороне клиента делают замены картинок на подходящие под тип экрана. Это всё равно вызывает лиший трафик, так как некоторые картинки успевают загрузиться, а если изображений много, замена, бывает, подтормаживает.

Насколько я вижу, даже в Эпл не придумали достойной альтернативы этой техники и у них сайт «улучшается» по мере загрузки — сначала грузятся обычные изображения, потом «ретиновые», если это необходимо.

Вообще, у Джипега, например, есть прогрессивная загрузка — по мере загрузки «прогрессивное» изображение не грузится сверху вниз, а становится всё чётче и чётче (хорошая иллюстрация этого есть в одном из параграфов «Ководства»). Надо будет поэксперементировать в эту сторону — нельзя ли прервать передачу на нужной детализации, если экран не «ретиновый».

А пока, у меня такое решение. Используем старые-добрые «печеньки» и mod_rewrite.

На стороне клиента первой строкой каждой нашей страницы ставим проверку по «ретиновые» экраны с установкой «печенья»:
<script>if(window.devicePixelRatio>=2)document.cookie='retina=1'</script>
Этот скрипт выполнится первым и все дальнейшие запросы на сервер будут содержать строку «retina=1», если мы имеем дело с Ретиной. Все изображения, для которых у нас есть две копии — обычная и «ретиновая» (в два раза большая) называем одинаково, но с постфиксом «@2x» для большей, при этом в коде указываем данные разрешения для более мелкой картинки:
<img src="/images/owl@2x.jpg" width="400" height="560" alt="Совушка">
Сейчас, конечно, Апач теряет популярность, но я воспользуюсь синтаксисом mod_rewrite, желающие могут переделать в Энжин Икс или какой-то другой синтакис:
RewriteEngine On

RewriteCond %{HTTP_COOKIE} !retina=1
RewriteRule (.*)@2x\.(gif|jpe?g|png|webp) $1.$2 [L,NC]
Этот код означает, что если не установлено «печенье» «retina=1», то нужно убрать постфикс «@2x» из имени картинки.

В итоге, если у нас Ретина, «печенька» ставится в самом начале, все дальнейшие запросы к серверу идут с ней и картинки грузятся как указано в коде — например, если указано «owl@2x.jpg», то эта картинка и грузится.

Если у нас обычный экран, «печеньки» нет, запросы к серверу идут без неё и из картинок вырезается постфикс «@2x», т.е. картинка «cat.jpg» грузится по своему имени, а вместо «owl@2x.jpg» загрузится «owl.jpg».

Voilà!
66 комментариев
23 мая 2013 21:33

Инвертирование в CSS без фильтров

Немногие знают, что инвертирование части ХТМЛ-страницы можно и без новомодных ЦСС-фильтров. Правда, количество браузеров, где это можно сделать, всё уменьшается. В данный момент такая возможность всё ещё остаётся в Эксплорере (версия 8 и выше) и «Опере» (7.0 и выше). Так как «Опера» скоро перейдёт на Вебкит, где этой возможности нет и не было, останется один Эксплорер. Файэрфокс лишился поддержки этой функции в версии 3.0 и возвращать её пока не планирует.

Я говорю о поддержке значения invert свойства outline-color. Это значение говорит браузеру, что нужно инвертировать всё, что лежит ниже. Пользоваться не очень-то удобно, но сойдёт при необходимости, результат может выглядеть, например, так: Инвертирование при помощи outline-color (33.90КиБ) Наложить сверху элемент с аутлайном можно любым способом, я использовал position: absolute:
<style>
.invert {
    outline: invert solid 75px;
    position: absolute;

    width: 50px; height: 0;
    margin: 75px 0 0 75px;
}
.content {
    width: 200px;
    height: 150px;
    position: absolute;
    left: 200px;
    top: 200px;
    text-align: center;
}
</style>

<div class="content">
    <div class="invert"></div>
    <img src="http://bolknote.ru/i/foto.jpg">
</div>
Для того, чтобы высчитать размеры накрывающего блока, нужно немного арифметики. У меня большую размерность имеет ширина (накрываемый блок размером 200×150), поэтому будем плясать от неё. Высота накрывающего блока должна быть в этом случае равна нулю, ширина — разности между шириной и высотой накрываемого блока, outline-width, margin-top и margin-left — половине высоты накрываемого блока.

Думаю, ни для кого не составит труда самостоятельно провести вычисления для обратного случая — когда высота больше ширины.
1 комментарий
22 апреля 2013 12:36

Какие графические форматы поддерживает ваш браузер?

Форматы, поддерживаемые браузерами (94.84КиБ) Я тут скрипт накидал, который проверяет какие графические форматы поддерживает ваш браузер. Проверяется JPEG, GIF, PNG, XMB, WebP, BMP, SVG, JPEG XR, TIFF, PDF, EMF, WMF, WBMP (Wireless BMP), JPEG-2000, ICO, APNG и MNG.

Тестируется поддержка в теге IMG.

Любопытно, что «Сафари» до сих пор поддерживает JPEG-2000, а «Опера» — WBMP (как единственный десктопный браузер, поддерживающий WAP, где WBMP и применяется).

Дополнение: оказывается, SVG в моем тесте был не до конца верный (я его просто сконвертировал из гифа 1×1 какой-то программой), так что скриншоты теста в браузерах верны не до конца, «Хром» и «Сафари» (т.е. браузеры на вебките) не поняли мой SVG.
17 комментариев
29 марта 2013 10:46

Тег шаблона (NOEMBED?)

Где-то видел спецификацию на тег TEMPLATE, для шаблонов в HTML. Его смысл в том, что содержимое не добавляется в DOM (дерево) документа, не засоряет дерево, что может быть очень полезно, если шаблонов много и веб-приложение активно работает с деревом. Работа с DOM одна из ресурсоёмких операций, ни к чему нагружать браузер ещё и шаблонами.

Традиционно в HTML4 для этого используют тег SCRIPT у указанием какого-нибудь несуществующего языка:
<script type="text/x-template" id="template-ok">
<div><div class="button">OK</div></div>
</script>
Либо используют комментарии (у Сергея Чикуёнка был рассказ про веб-читалку книг, там текст книги клался в комментарий, чтобы браузер его не парсил, книга большая и это занимало много времени), но к ним сложнее адресоваться (надо оборачивать тегом).

Был раньше такой нестандартный тег COMMENT, но его сейчас никто не понимает, даже Эксплорер прекратил его поддержку, в данном случае он бы пригодился.

Мне вчера ночью подумалось, что можно использовать и более лаконичные теги — NOFRAMES или NOSCRIPT. Первый показывает своё содержимое, если браузер не поддерживает фреймы, второй, если выключены скрипты. Если выключенные скрипты ещё встречаются у сетевых параноиков, то браузера без поддержки фреймов сейчас и не встретишь, а если таковые и есть, то веб-приложения им не понянуть.

Особенность же тегов в том, что они в нормальных условиях являются аналогом комментария, то есть не добавляют своё содержимое в DOM, поэтому они вполне пригоды на роль шаблонного тега.
<noframes id="template-ok">
<div><div class="button">OK</div></div>
</noframes>

<script>
alert(document.getElementById('template-ok').innerText); // содержимое шаблона
</script>
Не сказать, что это как-то по-особенному семантично или чем-то лучше тега SCRIPT (разве что короче), просто ещё один вариант.

Когда я уже дописал эту заметку, мне пришла в голову мысль, что а) тег NOEMBED был бы, наверное, более семантичем, чем NOFRAMES, он имеет отношение к встраиванию контента, а я совсем про него забыл, б) тег EMBED был бы, наверное, ещё более семантичен, но, к сожалению, он слишком тяжёл для браузера, надо испытывать, но я предполагаю, что даже если контент явно незнакомый, браузер всё равно попытается угадать что это. Но надо провести испытания, конечно же.

Так что, я бы остановился бы на NOEMBED. Во-первых, это тег ещё короче, во-вторых, обладает хоть какой-то семантикой, которую можно трактовать как не вставлять (no-embed) содержимое в дерево документа.
5 комментариев
5 марта 2013 05:46

«Крестики-нолики» на HTML и CSS

Давно хотел попробовать сделать «крестики-нолики» только на HTML и CSS, без использования скриптов, вот — сделал.

HTML+CSS only tic-tac-toe (24.29КиБ)

Играет на уровне мастера, то есть пытается либо выиграть, либо свести к ничьей. Вычисления позиций проводил через реализацию «крестиков-ноликов» Стефена Остермиллера. Там на ДжаваСкрипте, я написал обвязку для перебора и запускал через «Ви8». Поскольку мне хотелось придать игре налёт винтажности, добавил лёгкий фон конца девяностых, шрифт курсивом и тень. Всё как в старые добрые девяностые, возможно только анимированного ГИФа какого-нибудь нехватает.

Кстати, несмотря на всю винтажность, от браузера требуется поддержка CSS3, включая трансформации.

Я сильно не тестировал, спать уже надо ложиться. Если будут ошибки, пишите, постараюсь поправить, если только они не относятся к недостаткам алгоритма Остермиллера. Всё-таки это скорее концепт, чем полноценная игра.
20 комментариев
23 октября 2011 22:17

В IE10 не будет попадать под conditional comments

«Микрософт» решила, что conditional comments не должны обнаруживать IE10. То есть, по идее, условия «[if IE]», «[if IE 10]», «[if IE gt 5]» работать не должны, а «[if IE lte 9]» по-прежнему будет работать.

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

Because some features in earlier versions of IE aren’t compatible with HTML5 parsing, we’ve removed them from IE10 mode. Sites that rely on these legacy features will still work when running in legacy modes. This way, sites that work today will continue to work with IE10 even if the developers of the site don’t have the time to update them.
Причём «Микрософт» тут же признаётся, что парсер ни при чём:
This means conditional comments can still be used, but will only target older versions of IE.
Если часть условия conditional comments всё-таки будут срабатывать, то причём тут парсер HTML5? Условия, которые оставили совместимы с HTML5, а те, которые убрали — нет?

Скорее «Микрософт» этим шагом заявляет, что «мы так всё идеально поддерживаем, что нет нужды отделять IE от других браузеров». Может быть это и так. Но я был бы рад, если бы conditional comments появились в других браузерах, а не исчезли был из IE.

Помимо этого из IE10 исчезнут Element Behaviors и XML Data Islands.

Добавлено позднее: мы тут поговорили с Вадимом Макеевым, кажется, я ошибаюсь. В режимах эмуляции старых браузеров (вероятно в этот момент работает отдельный движок), conditional comments работают, в режиме IE10 — нет.
16 комментариев
7 июля 2011 10:00

Увеличение числа параллельных соединений браузера к одному домену из HTML

Большинство разработчиков сайтов уже знают, что число соединений к серверу у браузеров лимитированно. Старые версии браузеров используют только два соединения на сервер, более свежие побольше (например, «Опера» 11.10 — аж 16).

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

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

Если сайт и канал вполне выдержат и большее количество соединений от одного пользователя (с учётом посещаемости), то есть хитрость, которую часто используют — загружать статику (картинки, файлы стилей и прочее) с других доменов. Их не обязательно располагать на других серверах, достаточно дать одному серверу несколько имён и использовать их для загрузки.

Выглядеть это может так: static1.example.org, static2.example.org и так далее. «Яндекс», к примеру, грузит свои данные с домена yandex.st. Как видите, подходит другой домен любого уровня.

Хорошо, когда есть возможность завести любое количество доменов какого-нибудь уровня на своём хостинге. Далеко не все хостеры предоставят такую возможность бесплатно, а простому блогеру платить за ещё одно имя только ради ускорения загрузки вряд ли захочется.

Ничего страшного, чаще всего у пользователя такого хостинга аж четыре домена, просто мало кто об этом подозревает. Первые два достаточно очевидны — хостер часто, кроме какого-нибудь example.org, заводит ещё и www.example.org. Но ведь это два разных домена!

Ещё два не так очевидны— это домены «example.org.» и «www.example.org.». Обратите внимание на точку в конце домена.

Мои эксперименты (проверял на сервисе BrowserShots, операционные системы Linux, Windows XP, Mac OS X) говорят о том, что браузеры умеют с ними работать, то есть картинки с URL, где имя домена кончалось на точку, грузились нормально.

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

В эксперименте я выставил максимальное количество соединений к серверу в единицу («Опера» и «FireFox» позволяют это сделать, где это делается в браузерах на WebKit я не знаю, подскажите, если знаете) и создал две HTML-страницы: одну, где две картинки из моего скрипта грузятся с одного домена, вторую, где одна из них грузится с домена с точкой.

Варианты загрузки (49.40КиБ)

На скриншоте хорошо заметен результат и видно где какой эксперимент (по колонке «Домен»). По скриншоту видно, что я использовал хорошо всем знакомый FireBug, но на Dragonfly из «Оперы» картина такая же.
26 комментариев
18 апреля 2011 02:37