Browsers

Val Petruchek

подписывайтесь, а то хуже будет!  

ПОДПИСЫВАЙТЕСЬ НА RSS

“Каноническое” расположение скрипта (shared javascript)

23.04.08 @ 19:27 — JavaScript, Browsers

Вот один из способов, которым можно реализовать мою идею о загрузке javascript из локальной зоны браузера: добавление тегу script атрибута shared, обозначающего каноническое расположение библиотеки:

<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js” shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”></script>

Если в кеше браузере уже есть скрипт с uri, указанном в shared, то его можно будет не грузить.

Это — потенциальное дополнение к тегу script, которое может появиться в HTML5. Об этом рассказывает создатель JavaScript Brendan Eich (via Alex Moskalyuk).

Остановить воспроизведение animated gif в браузере

21.02.08 @ 13:12 — Browsers

Совершенно случайно обнаружил, как остановить воспроизведение анимированного гифа в браузере: достаточно нажать Escape.

Работает в Firefox, IE. В Opera не работает.

Опера вообще странный браузер: удобный, быстрый, лёгкий. Только то, что надо, не работает.

WAP сайты

02.12.07 @ 23:32 — Browsers, WebSites

Оказывается, Opera умеет отображать WAP-сайты. Готовый эмулятор.

(Она ещё и торренты качать пытается; не знаю, правда, насколько успешно.)

Отдельный привет хочется передать программистам ленты.ру, wap-версия сайта которой стабильно глючит (видимо, их любимое число — 404).

А Кукуц, тем временем, передаёт привет разработчикам Оперы за то, что в ней нет настройки “спрашивать разрешение на закрытие окна”.

Грузинская Опера

28.10.07 @ 13:02 — Browsers

Моя Opera заговорила на грузинском:

Opera Screenshot

Стандартный JavaScript FrameWork

JavaScript переживает сейчас вторую молодость, среди причин которой AJAX-бум и рост высокоскоростного доступа к интернету.

Банально, на JavaScriptе стали писать больше, чем писали раньше. И выяснили, что на чистом JavaScript много не напишешь: тяжёлое наследие Web 1.0, громоздкая Document Object Model, да и требования кросс-браузерности никто не отменял.

А кодить надо много и быстро, ведь на дворе уже Web 2.0 с его user-generated content, который эти юзеры хотят генерировать не с помощью стандартных кастрированных элементов управления родом из прошлого века, а с помощью нормальных графических интерфейсов, не хуже десктопных.

В результате для убыстрения разработки появились javascript библиотеки, количество которых наверняка перевалило за сотню. Называются они по-вебдванольски модно — “frameworkами”. Их главная цель — снять с кодера всю работу по обеспечению кросс-браузерности, обеспечив удобный доступ к DOM/AJAX и другие приятности, которых не хватает в чистом javascript. Выглядят эти фреймворки именно как библиотеками, подключаемые в документ с помощью тега <script>

Чем универсальнее фреймворк, тем он тяжелее. С одной стороны, это не проблема: есть GZIP, да и средняя скорость доступа к интернету растёт с каждым днём. С другой стороны, зачем грузить больше?

“Стандартом” отрасли ни один фреймворк не стал — все выбирают то решение, которое кажется удобней, и грузят пользователю именно его.

Рассмотрим гипотетическую ситуацию — существование стандартного javascript фреймворка. Стандартность означает поддержку браузерами.

В случае javascript-библиотеки эта поддержка является всего лишь гарантией того, что браузер где-то у себя локально хранит исходный код этой библиотеки. Разработчик может подключить фреймворк точно так же тем же тегом <script>, только грузить код не со своего сайта, а из локальной зоны браузера.

Если бы такой стандарт появился, и стал бы обязательным для поддержки всеми вебдванольными браузерами, то это никак бы не затронуло разработчиков, использующих другие фреймворки: продолжайте подгружать пользователям библиотеки со своего сайта, как вы подгружаете сейчас. Разработчики, перешедшие на этот гипотетический стандартный фреймворк, получают бонус в виде уменьшения времени загрузки кода библиотеки. Соотвестственно, этот стандартный фреймворк мог бы стать действительно мощной библиотекой — грузить-то ничего не надо.

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

Заставить браузеры договориться о такой поддержке будет, наверное, непросто. Но её наличие может стать ещё одним аргументом в их войне. Например, если Firefox начнёт поддерживать несколько фреймворков, а другие браузеры не начнут, то в коде можно будет делать простую проверку на поддержку библиотеки и в случае её отсутствия подгружать библиотеку с сайта, а в случае поддержки грузить локально. Тогда сайты, использующие поддерживаемые фреймворки, начнут натурально работать быстрее в Firefoxе, и медленнее во всём остальном.

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

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

clid=9582

С некоторого времени у меня в логах появились рефереры вроде такого: http://www.yandex.ru/yandsearch?clid=9582&text=keyword

Стало интересно, что за clid=9582 такой. Из просмотра логов апача стало понятно, что это опера. Opera 9.02 никакого clid при поиске по яндексе не шлёт. А вот 9.20 и 9.21 шлёт именно это значение, т.к. Yandex представлен в настройках поисковиков следующим образом: http://www.yandex.ru/yandsearch?clid=9582&text=%s

Opera 9.20 иногда шлёт другое значение: clid=9403.

Похоже, недавно в список дефолтных поисковиков Оперы добавили Yandex.

Скрыть реферера (HTTP_REFERER)

26.06.07 @ 22:33 — Software, Browsers

Иногда при переходе по гиперссылке с одного сайта на другой возникает желание не сообщать сайту, на который переходишь, откуда ты пришёл.

Самый очевидный способ не передавать информацию о ссылающейся странице — скопировать ссылку в буфер и вставить её в адресную строку. Этот способ работает, но он не очень удобный: слишком много движений.

Все основные windows браузеры позволяют скрыть реферера гораздо быстрее. Для этого надо перетащить ссылку, по которой собираешься перейти, в район адресной строки.

В Opera и седьмом Internet Explorerе (к сожалению, шестого под рукой нет) ссылку надо перетаскивать на закладку. В Firefox ссылку надо перетаскивать на адресную строку. Адресная строка Internet Explorer не даёт сделать drop ссылки, а Opera даёт, но не делает автоматический переход по этой ссылке, как Firefox.

При таком способе перехода по ссылке (drug’n'dropом) страница-referrer не передаётся.

P.S. Задолбали неграмотные гики и американцы: Gray, Referer, Color.

Browser Clipart

Пришла в голову такая идея — было бы здорово, если бы браузеры умели отображать стандартные картинки самостоятельно, из своей внутренней библиотеки.

Пример: в html код вставляется тег рисунок с src=”image://hardware/computer/keyboard”. Браузер этот код интерпретирует и подставляет в страницу рисунок клавиатуры из своего клипарта. Список поддерживаемых рисунков является общепринятым стандартом по аналогии со списком английских наименований html-цветов.

Пишешь себе скрипт, и на лету вставляешь в него иконки, не тратишь время на поиск и последующую обработку. Рисунки могут не являться концептуальной частью дизайна сайта; у сайта может вообще отсутствовать дизайн — Browser Clipart отлично справится с «раскраской» таких сайтов.

Браузеры карманных устройств могут иметь специальный клипарт с рисунками маленького размера, или иметь укороченный вариант клипарта.

Экономия на траффике незначительная, имеет смысл только для всяких gprsов.

Ну а пользователь может скачивать себе клипарт-темы: стандартные рисунки, нарисованные в разных стилях.

« Previous Page —   
Реклама::

 
Реклама::