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

Для устранения мигания нужно подключить к веб-странице небольшой код на JavaScript:

var m = document.uniqueID
&& document.compatMode
&& !window.XMLHttpRequest
&& document.execCommand;

try{
     if(!!m)
      {
         m("BackgroundImageCache", false, true)
      }
   }
   catch(oh){};


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


Поисковик по вину. Поисковик предлагает жителям америки здесь же на сайте и купить коллекционное вино. Интерес для меня: посмотреть на рекомендации, почитать, узнать сколько гипотетически бутылка того или иного вина может стоить, что стоит пить, а что нет :) Иногда эти знания важны особенно на томных аристократически интеллектуальных вечерах www.snooth.com

Почему компьютерный софт стал нас раздражать? Было ведь время, когда новый релиз популярной программы был настолько восхитителен и полезен, что мы не могли удержаться, чтобы не установить и не попробовать его в деле. А сейчас возникает такое ощущение, что софт специально создаётся таким, чтобы выводить нас из себя: начиная от постоянных автоматических обновлений и запросов на регистрацию, и заканчивая истечением «срока годности», что портит удовольствие даже от самого хорошего приложения. Маркетологи победили разработчиков, а программы от этого стали только хуже.

Я поговорила с другими редакторами PC World и составила этот список наиболее раздражающих факторов в софте. Будем надеяться, что издатели ПО обратят на него внимание.

1. Антипиратские меры
Я понимаю, что издатели хотят получать деньги за свою работу и что они не могут распространять софт под честное слово. Однако некоторые технологии, которые созданы для проверки честности, на самом деле портят нам жизнь больше всего.

Вы когда-то видели этот лоадер:

Или вот этот:


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

По моему, скрипт интернет-магазина является своего рода, лакмусовой бумажкой для веб-студий. У любой приличной компании или хорошего программиста, занимающихся созданием сайтов, в портфолио обязательно есть какой-никакой интернет-магазин и по нему можно точно определить профессионализм разработчика. Однако из-за того, что магазины охватывают широкий спектр технологий и функционала, создавать магазин каждый раз «с нуля» не имеет смысла. Гораздо проще взять готовый скрипт и исправить его под свои нужды. Возникает логичный вопрос — а какой скрипт брать? В этом я и попытаюсь разобраться.

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

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

Казалось бы просто, но.
Когда через несколько недель после начала сборки проекта до проекта добираются тестировщики, они хватаются за голову. В верстке обнаруживается десятки несоответствий дизайну. Баги сыплются на головы программистов и верстальщика. Следя за сборкой, дизайнер погружается в грусть все глубже и глубже, его состояние на границе отчаяния, а дизайн в забвении (как можно положить “это” в портфолио?!). Верстальщик не прекращает попыток фиксить баги, но они появляются быстрее, чем он успевает их читать.

Часто, когда мы сдаем проект клиенту, мы теряем контроль над HTML-кодом. Иногда клиент использует CMS (Системы Управления Контентом), которые дают ему полный контроль над теми или иными частями HTML-кода. Иногда клиент просто использует наши темплейты для вывода своего кода в документ.
В большинстве случаев довольно тяжело проинформировать клиента о том, как использовать темплейты или CMS, которые вы ему предоставляете, а иногда просто неприемлемо толкать пламенные речи о семантической верстке и веб-стандартах. Клиент может/будет использовать «старую, добрую разметку», ту, которую он знает, просто потому что она работает и выглядит так как он привык. Скорее всего в ней будут присутствовать нежелательные (deprecated) тэги и атрибуты, такие как bgcolor, align и «вечный» font. Эта статья о том, как блокировать нежелательные HTML-тэги с помощью CSS, тем самым аккуратно направляя клиента в правильном направлении.

Я познакомился с Ruby сравнительно недавно, благодаря чудесному фреймворку Ruby on Rails. Я не считаю себя экспертом в Ruby, но я прочитал PickAxe, написал несколько утилит на Ruby для личного пользования, а также разрабатываю на Rails в свободное время.

<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

Перевод статьи «55 Reasons to Design in XHTML-CSS».
В случайном порядке здесь представлены мои 55 причин создавать только бестабличные сайты, используя валидный XHTML для разметки, CSS для форматирования и Flash только в качестве уместной вставки. Под бестабличностью я понимаю избегание форматирования контента таблицами (или «супом» из заменяющих таблицы div-ов) и нацеленность на как можно более семантичную разметку. Некоторыe из перечисленных причин объясняют, «почему не использовать простой HTML», некоторые — «почему не сделать все на Flash», некоторые относятся как к первому, так и ко второму.
Я знаю, что эта тема обсуждалась множество раз, но все равно выскажусь

На прошлой неделе Бил Скотт (Bill Scott) анонсировал Protoscript — простой скриптовый язык для создания прототипов а-ля Ajax. При помощи Protoscript очень легко «вдохнуть жизнь» в элементы интерфейса.

Как известно, ведущие IT-корпорации стремятся заполучить к себе лучших сотрудников. Конкурс достигает нескольких сотен человек на место. Как отобрать среди них действительно лучших? Ведь средний балл аттестата и хорошее резюме на самом деле не могут точно отразить интеллектуальный потенциал программиста. Один из вариантов — задавать нестандартные задачки, например, сколько мячиков для гольфа помещается в школьный автобус или как измерить вес «Боинга-747»?

Мы уже приводили примеры таких задачек (в комментариях к той статье хабралюди сообщают, что подобные задачки задают на собеседованиях не только в Google и Microsoft, но и во многих российских IT-компаниях). Теперь, благодаря журналу Business 2.0 и опрошенным ими хедхантерам, стали известны ещё несколько таких задач. Вот они.

По просьбам трудящихся — перевод статьи Пола Грехема (Paul Graham) ‘Holding a Programm in One's Head’.

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

Примечание: мини-статья написана для новичков

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

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

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

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

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

читать дальше на webo.in →

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

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

(по версии WhenPenguinsAttack.Com)

После длительного поиска хорошего шаблонного движка на PHP, Justin Silverton составил следующий список с краткими описаниями.

Примечание: ниже перевод статьи «Boost Your Hyperlink Power». В ней освещается использование атрибутов rel и rev, а также некоторые микроформаты.

Часть HTML-тегов и атрибуты мы используем каждый день в свой работе. Заголовки, параграфы, списки и картинки являются основой разметки каждого веб-разработчика. Но наиболее распространенным элементом, наверное, будет ссылка — простой тег, который связывает воедино все страницы, создавая ту самую беспорядочную структуру, которую мы называем Всемирная Сеть Интернет (WWW).

Ссылка как она есть

Весь потенциал ссылок заключается в атрибуте href, сокращение от hypertext reference. Он создает одностороннюю связь текущей страницы с другим ресурсом, обычно другой такой же страницей в интернете:

   <a href="http://allinthehead.com/">

Атрибут href находится в открывающем теге a, между открывающим и закрывающим тегами находится текст для описания ссылки:

   <a href="http://allinthehead.com/">Drew McLellan</a>

«Ну и что», — скажите вы. — «Это я все и так знаю», — и будете абсолютно правы! Но у ссылки есть еще кое-что, кроме атрибута href.

Недавно решил поизучать framework’и для PHP.
Решил изучать CodeIgniter, но столкнулся с проблемой — отсутствие какой-либо документации на русском языке.
Вот я и решил открыть блог посвященный CodeIgniter.
Для начала я собираюсь перевести user guide по CodeIgniter.
А там посмотрим)
Попробую сделать, что-то типо Введение в Zend Framework.

Адрес блога.

Кто может помочь с переводом, пожалуйста, обратитись ко мне. Можно по ХаброПочте.

Я думаю, если документация по одному из не плохих (как я думаю) framework'ов на php будет на русском языке, то удет хорошо.