Еще в виртуальной машине есть IE 8 Beta 1 и Firefox 2, плюс в стареньком G4 Cube живут маковские Safari и Firefox.
Третий Firefox пока не ставил и не щупал (что-то я туплю на самом деле, надо поставить). И для полного счастья еще не хватает Konqueror (надо бы тоже на досуге поставить).
Вообще я стараюсь повседневно использовать более старые браузеры и не ставить последние версии как основные. Например, я был последним из могикан в Студии у которого дефолтный IE был версии 5.5.
Изучал тут статистику использования браузеров за май 2008 года...
| Firefox | 43,58% | тыдыщ |
| IE 6.0 | 17,56% | |
| IE 7.0 | 14,37% | |
| Opera 9.x | 18,36% | |
| ... | ||
| IE 5.0 | 0,55% | |
| IE 5.5 | 0,07% |
| IE 6.0 | 47,37% | тыдыщ |
| IE 7.0 | 30,72% | |
| Firefox | 10,64% | |
| Opera 9.x | 8,45% | |
| ... | ||
| IE 5.0 | 0,33% | |
| IE 5.5 | 0,12% | |
| IE 4.0 | 0,09% | фигасе |
| IE 6.0 | 30,89% | |
| IE 7.0 | 25,61% | |
| Opera 9.x | 25,46% | тыдыщ |
| Firefox | 14,91% | |
| ... | ||
| IE 5.5 | 0,07% |
Можно сделать несколько интересных выводов. Во-первых, видно, что статистика использования браузеров сильно зависит от сайта. Статистику, которую обычно предлагают нам всякие «исследования аудитории Рунета» можно назвать средней температурой по палате.
На сайте Студии зашкаливает Firefox. Ну оно и понятно. Кто ходит на сайт Студии? Веб-дизайнеры, веб-разработчики и прочие веб-интересующиеся — «продвинутые» ребята, использующие «правильный» браузер.
Банковский сайт — засилье Internet Explorer, причем с уклоном в сторону более старых версий. Кто ходит? Офисные работники на старых, давно не апгрейженных компах.
25% Оперы в интернет-магазине? Моя теория такая. Добросовестный человек занимается интернет-шоппингом в свободное от работы время с домашнего компьютера. По всей видимости, Опера — выбор многих рядовых пользователей для серфинга из дома.
Примерно от трети до половины пользователей IE проапгрейдились до IE 7.0. И это хорошо. Признаюсь, я стал уже немного забивать на IE 6.0. Скажем, на неработающий в IE 6.0 псевдокласс hover не у ссылок. Раньше писал джаваскриптик, который ловил onmouseover/onmouseout и навешивал/убирал класс hover. А сейчас забил.
Тем не менее, еще около полпроцента пользуются IE 5.0 и IE 5.5. И это до хрена! При посещаемости 50 000 в день, это 250 человек. Обязательно нужно проверять сайт в этих браузерах. Контент должен читаться, навигация должна работать, человек должен мочь выполнить свою задачу с которой он пришел на сайт.
that и this сидели на трубе…
Как известно, this внутри вложенных функций (inner functions) равен глобальному объекту (global object). Из-за этого приходится писать нелепую конструкцию var that = this; (господи, сколько же раз я написал эту строчку!)
Пример:
var test = {
init: function () {
this.txt = 'Test!';
var that = this;
window.setTimeout(function() {
alert(that.txt);
}, 1000);
}
};
Как же избавиться от ненавистного that?
Для этого попробуем воспользоваться методом apply, который позволяет задать контекст (чему будет равен this) у функции. Однако, применить apply к callback-функции передаваемой в setTimeout нельзя, поскольку apply сразу выполняет функцию к которой он применен. Поэтому напишем вспомогательный метод scope.
Function.prototype.scope = function (o) {
var fn = this;
return function () {
return fn.apply(o, arguments);
};
};
Теперь перепишем наш пример, используя метод scope.
var test = {
init: function () {
this.txt = 'Test!';
window.setTimeout(function () {
alert(this.txt);
}.scope(this), 1000);
}
};
Ура, мы избавились от that!
Плюсы:
var that = this;this вместо трижды злоебучей thatСпорные моменты:
thisИзначально хотел опубликовать эту заметку в Техногрете, но передумал — не могу с высокой трибуны рекомендовать решение, которым, возможно, сам не буду пользоваться :)
Вчера ночью, засыпая, подумал: «Так, по какому XSL-шаблону сон выводить будем?» Крыша поехала, ага :)
Tell me about your worst professional mistake you’ve made and what you learned from it.
Tough Interview Questions and How to Handle Them
Дело было в далеком 2002 году. Я только пришел в Студию и занимался в основном поддержкой существующих сайтов, в том числе одной очень уважаемой автомобильной компании.
Передо мной стояла задача: добавить на сайт еще одну модель автомобиля — описание, технические характеристики, фотогалерею, короче говоря, несколько страниц с картинками.
Сайт был устроен таким образом, что все картинки заливались через систему администрирования (сделанную не мной), которая присваивала каждой картинке id-шник, переименовывала их по этому id-шнику (получалось, например, 157.jpg) и складывала в папку /images/.
У нас была копия сайта на локальном сервере, где я и выполнил задачу. Настало время переноса на рабочий сайт. Вот тут-то и пробил роковой час — не долго думая, я скопировал все содержимое папки /images/ с локального сервера на живой. Набрав в браузере адрес сайта, чтобы проверить все ли хорошо после переноса, я потерял дар речи и замер в ужасе. Сайт выглядел просто феерически. Все картинки перепутались: на месте логотипа было колесо, вместо слогана — кусок бампера, вместо изображений автомобилей вылезли навигационные плашки, одним словом, наступил пиздец.
Как позже выяснилось, локальная копия сайта на самом деле, сука, не была «копией» в прямом смысле этого слова. Локальная и живая версии сайта уже давно разошлись. Что самое западло, названия картинок не совпадали. Чтобы перенести картинки на живой сайт, нужно было залить их через админку живого сайта.
Что же было дальше? Мы с менеджером побежали к админам, и они, дай им бог здоровья, все восстановили из последнего дампа. В общем-то все обошлось, но люди, зашедшие на сайт в эти полчаса, наверное, выпали в осадок от увиденного :)
Чему же научила меня эта ошибка? Самое главное, всегда подвергать сомнению и проверять все свои предположения. В данном случае я не проверил свое предположение об идентичности локальной и живой версий сайта, за что и поплатился.
А еще, я стал бекапить файлы, которые собираюсь перезаписать на живом сайте. Дамп админов — хорошо, а свой бекап тоже не помешает :)
Занимаясь веб-разработкой, часто требуется посмотреть как выглядит сайт при определенном разрешении. Переключать разрешение монитора долго и муторно, гораздо проще подогнать размер окна браузера. Обычно это делают с помощью плагина или специальной программулины.
Уже очень давно для ресайза окна браузера я пользуюсь закладками в самом браузере — удобно, всегда под рукой и не нужно держать постороннюю приблуду для этого. Решение работает в Firefox, IE, Safari. Не работает в Opera. Вот пошаговая инструкция.
1. Поставьте закладку на любую страницу, хотя бы на страницу, которую вы сейчас читаете.
2. Откройте свойства новой закладки.
3. В поле Name напишите 1024x768. В поле Location введите javascript:window.resizeTo(1024,768);
Готово! Нажмите на получившуюся закладку и окно браузера изменит свой размер на 1024×768.
Аналогично можно сделать закладки для остальных разрешений.
У меня в Firefox и IE настроено так: для самого популярного разрешения 1024×768 закладка находится в тулбаре, для остальных разрешений закладки в меню.
Кроме того, в Firefox для закладки можно задать ключевое слово. Если потом набрать это слово в адресной строке браузера и нажать Enter, то сработает соответствующая закладка. Например, для 1024×768 я задал ключевое слово «1». Удобно для любителей работать с клавиатурой: F6 (фокус в адресную строку), 1, Enter. Вуаля! Ресайз менее чем за 1 секунду!
На десерт:
Когда-то читал интервью с каким-то монстром программирования, где он упомянул, что проводя собеседования с устраивающимися на работу программистами, всегда просит их описать свою модель времени, как они видят себе год, неделю, день. По его мнению (с которым я согласен), в голове у каждого программиста обязательно должна быть четкая модель времени. Это такой своеобразный индикатор, что человек умеет структурировать окружающую его информацию — совершенно необходимый навык для программиста.
Год представляется мне в виде таблицы из трех строк с четырьмя месяцами в каждой строке.
Важны переходы на новую строку, особенно переход декабрь—январь, очевидно, связанный с Новым годом, и переход август—сентябрь — начало учебного года. Переход апрель—май явно не выражен и размыт. Ощущение такое, что как будто апрель иногда хочет перелезть на вторую строку или, наоборот, май пытается запрыгнуть на первую. Апрель вообще какой-то особенно безликий месяц, при мысли о нем он не сразу визуализируется на схеме. Вероятно, это от того, что в моей жизни не было важных событий в апреле.
Дни недели устроены в моей голове точно также, как они были устроены в школьном дневнике. Подозреваю, что большинство жителей нашей страны представляют себе именно такую схему недели. Неделя четко поделена пополам. В первом столбце — понедельник, вторник, среда. Во втором — четверг, пятница, суббота. Воскресенье — в уме. Я использую адресацию слева/справа, сверху/снизу/посередине. Скажем, планируя что-то на четверг, я мысленно помещаю событие в ячейку «справа, сверху».
Со временем суток дела обстоят сложнее — четкой и однозначной модели у меня нет. Есть довольно туманная схема, в которой день поделен на неравные плавающие уровни.
А как устроено ваше время?
Для рядового читателя все эти рассуждения о «семантической верстке» по большому счету до лампочки. Они приходят за контентом, а не для того, чтобы проверить правильность верстки. Какие в исходном коде теги и классы их абсолютно не волнует. Если сайт интересный, его прочтут при любой разметке. Если товар охуенный, его закажут не смотря на отсутствие семантики в верстке. Информация, которую создатели сайта хотят донести до людей, гораздо важнее и требует большего внимания, чем верстка этой информации.
Поэтому, когда я получаю для вывешивания на сайте скучный неинтересный на хуй никому не упавший текст, я очень огорчаюсь.
Разумеется, хорошая «семантическая верстка» повышает доступность сайта и видимость поисковыми системами. Конечно, правильная разметка выгодна самим разработчикам, т. к. облегчается поддержка проекта — новому кодеру легче вникнуть и найти место где нужно поправить.
Но интересный контент в тысячу раз важнее. Первых кого должна нанять студия веб-дизайна или интернет-компания, это копирайтера и редактора. Потом уже кодера.
Задача. Сделать для интернет-магазина Евросети средний рейтинг товара в виде звездочек с дробными значениями. Например, средний рейтинг = 3,6. Четвертая звездочка должна быть закрашена на 60%.
Очевидно, что нагенерить картинок для всех значений рейтинга невозможно. Поэтому, будем химичить в HTML и CSS.
Для начала нам потребуются две картинки: пустая звездочка 
и закрашенная 
.
Делаем дивчик высотой в одну звездочку, шириной в пять звездочек и бекграундом у него пускаем пустую звездочку. Внутрь кладем еще один дивчик такой же высоты с закрашенной звездочкой бекграундом. А вот ширину внутреннего дивчика высчитываем по формуле: rating * 100 / 5 (я сделал это XSL-ем на сервере, но можно и яваскриптом сделать). Получилось:
<div class="rating">
<div style="width: 72%;"></div>
</div>
Для версии без стилей внутрь наших дивчиков добавим текст «Оценка: 3,6». В обычной версии со стилями этот текст скроем.
Последний штрих — добавим тайтл, чтобы можно было посмотреть точное значение рейтинга.
Итого:
<div class="rating" title="3,6">
<div style="width: 72%;">Оценка: 3,6</div>
</div>
CSS:
div.rating {
width: 85px;
background: url('star-0-big.gif') repeat-x 0 0;
}
div.rating div {
height: 17px;
background: url('star-1-big.gif') repeat-x 0 0;
font-size: 1px;
text-indent: -9999px;
}
Элементарно просто можно адаптировать для:
Рейтинг этой заметки:
;-)