Гениальный в своей простоте способ заставить ссылку открыться в новом табе/окне, не используя нежелательный по рекомендации 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, и собственные умозаключения.

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

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

Даты и место проведения конференции веб-разработчиков Украины теперь точно известны: UA WEB 2007 состоится 29-30 октября, в конференц зале Президент Отеля, Киев.

Так же публикуем предварительный список докладов и докладчиков, разбитый на три секции — «Клиентские технологии», «Cерверное программирование» и «Бизнес, фриланс, аутсорсинг».

Напоминаем, что в четверг, 23 августа, в 19:00 в московском офисе компании Microsoft состоится последняя этим летом встреча докладчиков конференции HighLoad-2007. В программе — обсуждение завершенных к этому времени текстов докладов, выбор лучших выступлений (на данный момент конкурс составляет два доклада на место), проводы лета в ресторанчике Temple.

Приглашаются все неравнодушные! Точный адрес и план проезда описаны в статье на сайте конференции

Примечание: ниже перевод статьи Jeffrey Zeldman «E-mail is not a platform for design». В ней рассматривается текущая поддержка со стороны email-клиентов HTML-разметки писем. Статья во многом спорная и неоднозначная.

После стольких лет процветания интернета HTML-письма по-прежнему вызывают сильное отвращение (still sucks). Вы можете подумать, что я имею в виду «HTML-письма не отображатся корректно в некоторых email-клиентах» Однако, это лишь часть истины. Компании тратят сотни часов простых верстальщиков для создания HTML-разметок, которые могут не работать в Eudora или в Gmail или прекратить отображаться в Outlook.

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

Примечание: ниже перевод статьи «Ajax Best Practices: Don't Break Bookmarks», посвященной решениям, позволяющим пользователям корректно добавлять в закладки страницы сайта, сделанного при помощи AJAX-методов. Я постарался дополнить ее по мере сил, опираясь на обсуждение предыдущей статьи из серии.

Статья является второй из серии (здесь первая), посвященной устранению критики, которую сейчас так много адресуют использованию AJAX, и обзорам методов, которые помогут сделать ваш сайт чуточку лучше.

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

Например у вас широкий экран с разрешением 1600х1200. Вы открываете таб с Хабром, открываете таб с Википедией к примеру, а затем, находясь на активном табе, удерживая Ctrl кликаете по второму. Благодаря достаточной ширине экрана, оба сайта открыты одновременно и можно спокойно цитировать/копипейстить :)



Применений этому можно найти много. В идеале можно даже обеспечивать взаимосвязь веб-приложений средствами браузера. Можно реализовать drag&drop, можно реализовать администрирование сайтов, да все что угодно.

Соответственно, обьединенные табы будут выделены иконкой, их можно будет разьеденить, соеденить с другими и тд.

А какие мысли по использованию такой идеи появились у вас?

Примечание: ниже перевод статьи «Reporting bugs — a how-to guide», в которой приводится ряд нехитрых действий, которые могут помочь как пользователю, так и разработчику справиться с ошибками на сайте или в веб-приложении. В свете постоянного появления в Рунете проектов со статусом «бета», статья может быть особенно полезна.

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

Хочу пригласить участников хабра-сообщества к обсуждению тезисов конференции веб-разработчиков высоконагрузочных приложений HighLoad-2007. Тезисы 40 потенциальных докладов опубликованы на специальной странице, к каждому тезису подвязана информация о докладчике, есть возможность комментировать доклады, давать советы, рекомендации, задавать свои вопросы. Все комментарии будут донесены нами до докладчиков.

Примечание: ниже перевод статьи «Fixing The Web — Part 1», в которой поднимаются наиболее актуальные вопросы, касающиеся текущего положения вещей в Вебе.

Нуждается ли Веб в исправлениях?

История Веба насчитывает уже 16 лет. В первые 10 лет Веб-технологии развивались ошеломляюще быстро, но в последние 6 лет серьзных изменений в них не последовало. Насколько это хорошо или плохо? Существует ряд вполне понятных преимуществ существования стабильной среды разработки для любой технологии, но является ли Веб стабильным, или же он находится в застое? Постигнет ли Веб без инноваций такая же участь, как и любую другую технологию, что перестает следить за изменением пользовательских предпочтений и становится устаревшей?

Естественно, Веб играет роль, прежде всего, глобального информационного источника, но насколько хорошо при этом функционируют сами Веб-технологии? Чтобы ответить на этот вопрос, мы должны рассмотреть ряд проблем, которые существуют в Вебе:

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

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

Компания RuTube подготовила для каждого доклада preview-версию доклада, которую Вы теперь можете посмотреть прямо на сайте конференции РИТ-2007. Заходите в доклад — смотрите, читайте презентацию, комментируйте!