Сколько 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, и собственные умозаключения.

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

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

Даты и место проведения конференции веб-разработчиков Украины теперь точно известны: 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 потенциальных докладов опубликованы на специальной странице, к каждому тезису подвязана информация о докладчике, есть возможность комментировать доклады, давать советы, рекомендации, задавать свои вопросы. Все комментарии будут донесены нами до докладчиков.