<map
id="browser"
/''name="firefox"
/""name="sleipnir_gecko"
"name="safari"
""name="konqueror"
/name="ie"
name="opera"
name="lynx"
>



Атрибут name объекта с id=browser отдает название браузера. Основано на различии методов парсинга атрибутов элементов.

Источник: http://www.hedgerwow.com/360/dhtml/html-browser-detection.html

Уважаемые колеги!

Мы приняли решение перенести первую конференцию украинских
веб-разработчиков UA Web с октября 2007 на март 2008 года.

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

Все достигнутые договоренности в силе; все деньги, уже
уплаченные за участие в конференции будут по желанию
плативших либо возвращены в полном объеме, либо перенесены
на март 2008 года.

Спасибо за поддержку!

С уважением,
команда UA Web
Юрий Артюх, Евгений Некоз, Павел Рогожин и Олег Бунин
uaweb.in.ua

Наткнулся на днях на заметку о том, как можно с помощью JavaScript и HTML определить в каком конкретно браузере открыли страницу. И меня немного озадачила полезность такого и ему подобных ему решений.

Конечно же я имею в виду решения, основанные на всякого рода «хаках» и ухищрениях, на «слабостях» и ошибках тех или иных браузерах. Да, сейчас они хорошо выполняют поставленную перед ними задачу, но ведь может наступить момент, когда разработчики залатают одну маленькую дырочку, а что-то более «глобальное» будет работать по-прежнему коряво. И что тогда? Сайты «рухнут», а нового решения на тот момент может и не существовать…

В связи с этим у меня возникает вопрос: а действительно ли нужно ради каких-то рюшечек (это может быть некие ajax-фишки или что-то иное, но браузеро-зависимое) поиметь себе на пятую точку лишние, пусть даже и потенциальные, но проблемы?

Конечно же каждый разработчик/дизайнер/стартапщик/etc ответит на него по-своему, но лично я для себя определённую замету «на полях» сделал.

Мне часто задают вопрос о том, с чего начать молодому frontend-разработчику? Дабы облегчить свою участь и не перечислять каждый раз множество ресурсов сети, печатных и зданий и общих тезисов, я и написал этот материал.

В первую очередь следует знать, что кроссбраузерная верстка сродни магии. Объясняется это все банальной вещью, которую я озвучу так: ”Все мы ненавидим Internet Explorer!” Таким образом, 90% всей магии сводится к тому, чтобы заставить правильно сверстанный макет корректно отображаться в браузере Internet Explorer всех актуальных версий.

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

Крепкая теоретическая база поможет вам избежать множества неприятностей в практическом изучении верстки гипертекстовых документов. Очень важно получать знания порциями в правильном порядке.

Только что из типографии, забираем первый тираж книг по материалам конференций РИТ и HighLoad!!! Это просто бомба — книга по РИТ 632 страницы, Хайлоад — 242 ;))

До старта конференции осталось два дня! Следите за трансляцией от RuTube!

Довольно интересный материал "Serverwide Performance Benchmarking" в котором представлено исследование изменения производительности web-сервера в зависимости от типа файловой системы (Ext3, ReiserFS, JFS, XFS), размера буфера (shared buffer) PostgreSQL и наличия кэширования опкода в PHP (Advanced PHP Cache).

Абсолютным лидером среди ФС оказывается XFS, а из привычных ext3 — ext3 mode writeback noatime.
Немного странным выглядит малая эффективность PHP APC, но автор объясняет это простой и лёгкостью сайта, «там мало чего можно закешировать, но на бОльших проектах он обязательно поможет».

Via: opennet.ru

Ставим денвер на флэшку.

Идея пришла ко мне всвязи с тем, что дома стоит большой комп и ноутбук.

Решил попробовать поставить на флэшку и не мучиться. Вставил в комп, запустил run.exe и работаешь, закончил, вставляешь в другой комп работаешь дальше. При этом все изменения сразу делаются на флэшке.

Сколько HTML элементов (по спецификации HTML 4) ты можешь назвать за 5 минут? (всего 91 элемент)
Сколько свойств CSS (Level 2) ты можешь назвать за 7 минут? (всего 122 свойства)

Вот такие две интересные задачки на время, позволяющие проверить свою память. После прохождения теста можно получить симпатичную кнопочку с результатами. Баловство конечно, но интересное.

В подсказку чур не подглядывать ;)

Примечание: ниже расположен перевод статьи «KHTML vs. Gecko vs. Trident vs. Presto: Behind the Browser», в которой рассматриваются основные движки браузеров, история их возникновения и развития, а также некоторые философские вопросы, с ними связанные. В основном, речь идет о KHTML, WebKit и Gecko.

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

В любом случае, пользователей гораздо больше беспокоит, насколько их браузер безопаснее. Возможно, их тревожит, были ли старые версии браузера от Apple более безопасными, потому что использовали KHTML? Или, может быть, безопасность и удобство использования гораздо выше у Firefox от Mozilla Foundation, ибо он использует Gecko? Является ли Internet Explorer 7 (IE7) от Microsoft лучшим браузером на сегодняшний день, потому что использует движок Trident? Отчего так много возможных альтернатив?

«Почему мы используем не единственный браузерный движок? Это помогает замедлить инновационное развитие и предупредить появление ошибок, которые не обнаружатся во всех браузерах одновременно. В любом случае, несколько реализаций одного и того же лучше, чем одна», — комментирует Gene Spafford, профессор информатики в Purdue University, специально для LinuxInsider.

SQLyog — это один из лучших менеджеров для работы с MySQL с которым мне приходилось работать. Кроме интуитивно понятного дизайна он может похвастаться богатым функционалом.

Гениальный в своей простоте способ заставить ссылку открыться в новом табе/окне, не используя нежелательный по рекомендации W3C в XHTML, атрибут target:

<a onclick=«return !window.open(this.href)» hrеf=«www.google.com»>

Преимущества этого способа перед обычным open.window(url) в том, что если javascript отключен, то ссылка все равно сработает. Кроме того, ссылка будет проиндексирована поисковиками.

Проверено в FF2, IE6/7, Opera 9.20, Safari/Win.

<update>

Поведение браузеров при нажатии Ctrl+Click / Shift+Click:

В IE6 — в обоих случаях новое окно.
В IE7 — в обоих случаях новый таб (подозреваю что зависит от настроек браузера)
В FF2 — неадекват. ctrl+click открывает две вкладки, shift+click вкладку и окно
Opera — в обоих случаях новый таб
Safari/Win — в обоих случаях новое окно

При нажатии колесиком мышки ссылка срабатывает как обычно везде, кроме IE6, естественно.
</update>

В общем и целом, не стоит принуждать посетителей к чему-либо, предпочтительнее дать посетителю знать какого рода сама ссылка (файл [включая тип], внешняя/окно) с помощью иконок, которые можно легко прикрутить с помощью CSS, на пример вот так, тем самым давая ему возможность выбрать самому, где ее открыть.

Google Analytics предоставляет широкие возможности по сбору и анализу статистики сайта, но, способ отслеживания исходящих ссылок, предлагаемый в справочном центре…

<a href="http://www.primer.ru" onClick="javascript:urchinTracker('/outgoing/primer_ru');">

…мягко говоря, не очень удобен.

Поскольку сама возможность очень интересная, я решил все-таки использовать ее и при этом обойтись без прикрепления onclick к каждой внешней ссылке.

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

Большинство современных обзоров jQuery делают упор на дизайнеров и неопытных разработчиков. Я попытаюсь объяснить, почему она также нужна и опытным программистам.

Примечание: ниже представлен официальный перевод статьи «On having Layout» на русский язык. Статья не является окончательной. Этот перевод отражает 9 версию от 23.10.2007.

UPD текст статьи полностью убран в связи с его неконтролируемыми изменениями с момента публикации. Перепечатка доступна здесь

Преамбула

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

Примечание: ниже находится перевод статьи «Bring on the tables», в которой рассматривается использование таблиц по прямому назначению и некоторые методы по увеличению их доступности.

UPD: текст статьи полностью убран в связи с его неконтролируемыми преобразованиями с момента публикации.

Ребята из Rails Envy продолжают радовать новыми видео =)
По наводке хабраюзера Chapaev, совсем свеженькое и горячее:

Rails vs .NET

Rails vs PHP

FWC:SmartSelect 2.7

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

когда мне всё это надоело, я написал тулкит, который решает все эти проблемы одним махом.
этот тулкит позволяет максимально просто создать «поддельный» выпадающий список, который на первый взгяд идентичен стандартному тегу select, но лишенный всех его недостатков.

кроме того он позволяет использовать некоторые очень полезные функции, крайне популярные в последнее время. например, удобный API для управления списками и пунктами (создание, редактирование, удаление), ajax-подгрузка каскадных списков (когда содержимое некоторых списков зависит от других), а также создание простых текстовых полей с автоподстановкой значений при вводе (в том числе и из серверных ресурсов, аналогично Google Suggest).

все настройки для компонентов smartselect описываются в отдельном xml-файле или json-строкой.

Есть задачка, сделать виртуальный город, с максимальной эмуляцией, города как такового.

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.