Дизайнер очень хорошо постарался: страница выглядит очень красиво и современно. Осталось только перенести всё эту красоту из фотошопа в веб.

Центральный элемент страницы — сцена, на которой показываются новинки нашего каталога. На фоне сцены находится очень большая картинка с кулисами. Если присмотреться, то эти кулисы покрыты лёгким шумом, что придаёт им особый колорит:

Однако вся эта красота на проверку оказалась очень тяжёлой: в одной картинке объединилось всё худшее, что плохо влияет на сжатие. Это и красный цвет (даёт очень сильные артефакты сжатия в JPEG), и мелкий шум (сильные артефакты в JPEG; плохо упаковывается в PNG). Приемлемое качество картинки было достигнуто при размере в 330 КБ, что, на мой взгляд, довольно много для одной картинки. Очень хочется, чтобы главная страница загружалась как можно быстрее. Поэтому я решился на один эксперимент.

Изучаем картинку

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

Простой алгоритм монохромного шума выглядит так:

var canvas = document.createElement('canvas');
canvas.width = canvas.height = 200;
var ctx = canvas.getContext('2d');

// получаем все пиксели изображения
var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
var pixels = imageData.data;

for (var i = 0, il = pixels.length; i < il; i += 4) {
	var color = Math.round(Math.random() * 255);
	// так как шум монохромный, в каналы R, G и B кладём одно и то же значение
	pixels[i] = pixels[i + 1] = pixels[i + 2] = color;

	// делаем пиксель непрозрачным
	pixels[i + 3] = 255;
}

// записываем пиксели обратно на холст
ctx.putImageData(imageData, 0, 0);

document.body.appendChild(canvas);

Получим вот такой результат:

Вполне неплохо для начала. Однако нам не достаточно просто сгенерировать слой с шумной текстурой и наложить его на кулисы с полупрозрачностью. Если ещё внимательней присмотреться к картинке, то можно заменить, что там нет светлых пикселей, есть только тёмные. То есть монохромный шум должен быть наложен на картинку в режиме Multiply.

Режимы наложения

Каждый, кто работал с фотошопом и другими продвинутыми графическими редакторами, знает, что такое режимы наложения слоёв:

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

(colorA * colorB) / 255

То есть просто умножаем два цвета и делим результат на 255 (отсюда и название Multiply: «умножение»).

Доработаем нашу функцию: загрузим картинку, сгенерируем шум и наложим его в режиме Multiply:

// Загружаем картинку. Обязательно ждём, пока она полностью загрузится
var img = new Image;
img.onload = function() {
	addNoise(img);
};
img.src = "stage-bg.jpg";

function addNoise(img) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');

	// нарисуем картинку на холсте, чтобы получить её пиксели
	ctx.drawImage(img, 0, 0);

	// получаем все пиксели изображения
	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data;

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random() * 255;

		// накладываем пиксель шума в режиме multiply на каждый канал
		pixels[i] = pixels[i] * color / 255;
		pixels[i + 1] = pixels[i + 1] * color / 255;
		pixels[i + 2] = pixels[i + 2] * color / 255;
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Получим что-то типа этого:

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

Альфа-композиция

Процесс смешивание двух цветов с учётом прозрачности называется «альфа-композиция». В простейшем варианте алгоритм смешивания выглядит так:

colorA * alpha + colorB * (1 - alpha)

где alpha — это коэффициент смешивания (прозрачность) от 0 до 1. В данном случае важно правильно выбрать, что будет фоновым изображением (colorB), а что будет накладываемым (colorA). В нашем случае фоновой будет сцена, а шум — накладываемым.

Добавим в функцию addColor() дополнительный параметр alpha и модифицируем сам алгоритм с учётом альфа-композиции:

var img = new Image;
img.onload = function() {
	addNoise(img, 0.4);
};
img.src = "stage-bg.jpg";

function addNoise(img, alpha) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');
	ctx.drawImage(img, 0, 0);

	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data, r, g, b;

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random() * 255;

		// высчитываем итоговый цвет в режиме multiply без альфа-композиции
		r = pixels[i] * color / 255;
		g = pixels[i + 1] * color / 255;
		b = pixels[i + 2] * color / 255;

		// альфа-композиция
		pixels[i] =     r * alpha + pixels[i] * (1 - alpha);
		pixels[i + 1] = g * alpha + pixels[i + 1] * (1 - alpha);
		pixels[i + 2] = b * alpha + pixels[i + 2] * (1 - alpha);
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Получаем именно то, что нам нужно: слой шума, наложенный на картинку в режиме Multiply и прозрачностью 20%:

Оптимизация

У меня картинка генерируется примерно за 400 мс, что довольно заметно. Поэтому мы оптимизируем код, чтобы он работал быстрее.

Размер моей картинки 1293×897 пикселей, что в итоге даёт 1 159 821 итераций цикла. Это довольно много, поэтому в первую очередь нужно оптимизировать операции вычисления, а именно убрать ненужные и повторяющиеся операции.

Например, в цикле три раза высчитывается значение 1 - alpha, хотя это постоянное значение для всей функции, поэтому делаем новую переменную за пределами цикла:

var alpha1 = 1 - alpha;

Далее, при генерации пикселя шума используется формула Math.random() * 255, однако дальше мы делим этот цвет на 255: r = pixels[i] * color / 255. Соответственно, умножение и деление на 255 можно смело убирать.

Эти простые операции снизили время выполнения скрипта с 400 мс до 300 мс (-25%).

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

var origR = pixels[i],
	origG = pixels[i + 1],
	origB = pixels[i + 2];

Это экономит ещё около 40 мс.

С учётом всех оптимизаций функция addNoise() выглядит вот так:

function addNoise(img, alpha) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');
	ctx.drawImage(img, 0, 0);

	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data, r, g, b, origR, origG, origB;
	var alpha1 = 1 - alpha

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random();

		origR = pixels[i];
		origG = pixels[i + 1];
		origB = pixels[i + 2];

		// высчитываем итоговый цвет в режиме multiply без альфа-композиции
		r = origR * color;
		g = origG * color;
		b = origB * color;

		// альфа-композиция
		pixels[i] =     r * alpha + origR * alpha1;
		pixels[i + 1] = g * alpha + origG * alpha1;
		pixels[i + 2] = b * alpha + origB * alpha1;
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Скорость выполнения скрипта — около 170 мс (было 400 мс), что довольно неплохо.

Ещё больше оптимизаций

Внимательный читатель мог заметить, что картинка с кулисами — красная. То есть информация об изображении присутствует только в красном канале, в синем и зелёном её нет. Если её нет, зачем делать вычисления для этих каналов? Поэтому оставляем расчёты только для красного канала: конкретно в моём случае это даст аналогичный результат, а время выполнения снизит до 80 мс:

for (var i = 0, il = pixels.length; i < il; i += 4) {
	origR = pixels[i];
	pixels[i] = origR * Math.random() * alpha + origR * alpha1;
}

Добавлено: читатель @Sergeyev указал, что можно ещё сократить время выполнения скрипта (-20%), убрав ненужные операции:

for (var i = 0, il = pixels.length; i < il; i += 4) {
	pixels[i] = pixels[i] * (Math.random() * alpha + alpha1);
}

Результат

Результат получился довольно неплохим:

• Вес изображения снизился с 330 КБ до 70 КБ + 1 КБ пожатого JS-кода. На самом деле, картинку можно было бы ещё больше ужать, потому что слой с шумом скроет большинство артефактов JPEG-сжатия.
• Такая оптимизация соответствует практикам progressive enhancement: пользователи с браузерами, в которых нет canvas (например, IE6) или отключён JS всё равно получат картинку, но менее детализированную.

Единственный минус, который я вижу — это выполнение наложения каждый раз при загрузке страницы, в то время как обычная картинка может быть просто закэширована браузером. Но, во-первых, время выполнения наложения довольно низкое (80 мс), а во-вторых, как вариант, результат можно хранить в localStorage в виде data:url и при следующей загрузке страницы доставать из кэша. Но моя картинка занимает более 1 МБ, так что я не стал сохранять её — доступное пространство можно и нужно использовать с большей пользой.

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

Добавлено: некоторые читатели и Денис в частности справедливо заметил в комментариях, что практически идентичного результата можно добиться наложением слоя с шумом поверх картинки. Тут скорее речь идёт о не совсем удачном примере, выбранном для статьи, нежели о неправильности подхода в целом.

В JSDT меня больше всего привлекло следующее:

• Рефакторинг: переименование объектов, выделение блока в отдельную переменную, объединение определения переменной и присваивания и т.д. Некоторые вещи вроде выделения в метод пока толком не работают, но, надеюсь, в ближайшее время это будет исправлено.
• Валидация кода. Помимо обычной проверки синтаксиса, можно настроить более сложные проверки вроде поиска неиспользованных переменных, недостижимый код, переопределение переменной из внешней области видимости и т.д.
• Выделение фрагментов camelCase-переменных с помощью Shift+Alt+← и Shift+Alt+→
• Поддержка JSDoc.
• Удобный Outline/Quick outline; дополнительные окна, в которых показывается документация и код определения текущего объекта.
• Автоматическая отбивка кода при его перемещении из/в блок.
• Подключение внешних библиотек.
• Встроенный дебаггер.

Лучше всего будет, если читатель поставит Eclipse for JavaScript Web Developers и изучит все настройки и менюшки — в том числе контекстные — JSDT (лучше включить перспективу JavaScript), потому что возможностей действительно очень много и их сложно описать в одной статье.

Однако при всей «крутости» этой среды разработки, в ней есть ряд проблем, с которыми пришлось столкнуться прежде, чем окончательно перейти на JSDT.

Начинаем работу

Для того, чтобы полноценно использовать все возможности JSDT, обязательно нужно создать проект с JavaScript-природой. Делается очень легко: вызываем File > New > Project… и в появившемся окошке выбираем JavaScript Project. В появившемся диалоговом окне вводим название проекта и жмём Finish. По умолчанию создаётся веб-проект с поддержкой DOM, папкой с JS-исходниками является сам проект. Когда вы лучше освоитесь с JSDT, то сможете более тонко настраивать проект: указывать подключаемые библиотеки, исключать ненужные файлы и папки из индекса. Пока оставим как есть.

Module pattern

Главным преимуществом для меня в Spket IDE была поддержка современных паттернов, в том числе и модуля:

var module = (function() {
	return {
		method: function() {}
	};
})();

В Spket такая конструкция без проблем отображается в outline и по ней работает code complete, но в JSDT ни то, ни другое не работает:

Небольшой JSDoc исправит ситуацию:

/**
 * @type module
 */
var module = (function() {
	return {
		/**
		 * @memberOf module
		 */
		method: function() {}
	};
})();

Теперь работает как надо:

Но есть ещё одна проблема: приватные переменные и методы модуля не отображаются в Outline, а очень хотелось бы. Это можно исправить, описав самовызывающуюся функцию как конструктор несуществующего класса:

/**
 * @memberOf __module
 * @type module
 */
var module = (/** @constructor */ function() {

	function myPrivateMethod() {

	}

	return {
		/**
		 * @memberOf module
		 */
		method: function() {}
	};
})();

Как видно из примера, я описал несуществующий класс __module, двойное подчёркивание я использую в качестве своеобразного соглашения об именовании объектов. Проблема в том, что этот несуществующий класс попадёт в code complete всего проекта, и использование двойного подчёркивания — простой и понятный способ отфильтровать ненужные данные при вызове code complete. Однако этот недостаток очень легко можно превратить в достоинство: таким образом можно описывать структуры объектов, доступ к описанию которых затруднён из-за отсутствия строгой типизации в JS:

Поддержка популярных библиотек

Базовый набор библиотек для JSDT довольно невелик: это стандартные объекты JavaScript (Array, String и прочее) и стандартный DOM (HTMLElement, document и так далее). То есть если мы напишем, например, document. и вызовем code complete, то увидем список свойств и методов объекта document, экземпляра класса Document. Но современная веб-разработка немыслима без использования популярных библиотек вроде jQuery.

Имея в своём распоряжении JSDoc, можно создать описание практически любого популярно фреймворка и использовать его для подсказок в коде. Так как таких описаний в интернете найдено не было, я воспользовался своим любимым принципом «если хочешь, чтобы что-то было сделано хорошо, сделай это сам» и запустил проект, в котором создаю описания популярных библиотек и фреймворков, с которыми работаю:

jsdt-docs — JSDoc для популярных библиотек

В этом проекте сейчас есть следующие библиотеки:

• Modernizr 2
• Browser Addons — разные методы и свойства, которые почему-то отсутствуют в стандартном описании DOM в JSDT.
• console — небольшое описание объекта console, который присутствует в современных браузерах.
• CSS2Properties — список CSS-свойств для свойства style DOM-элементов. Несмотря на то, что он называется CSS2, в нём присутствуют и CSS3-свойства: такое название выбрано потому, что в стандартном описании Element.prototype.style является объектом класса CSS2Properties.
• JS SIgnals
• Node.JS
• Socket.IO
• Underscore.js.
• Zepto.js

Добавить библиотеку довольно просто:

1. Идём в настройки: Preferences > JavaScript > Include Path > User Libraries.
2. Создаём новую библиотеку: нажимаем кнопку New…
3. Вводим название библиотеки в появившемся окне и жмём ОК.
4. Выделив только что добавленную библиотеку, нажимаем на кнопку Add .js file… и выбираем один или несколько файлов, относящихся к данной библиотеке.

После того, как библиотека была создана, нужно добавить её в проект:

1. Идём в настройки проекта: Project > Properties > JavaScript > Include Path > Libraries.
2. Жмём кнопку Add JavaScript Library, выбираем User Library, а затем и библиотеки, которые хотим добавить.

Теперь у вас в проекте будет работать code complete для указанных библиотек:

Поддержка jQuery

Добавление поддержки своего любимого фреймворка оказалась не такой уж и простой задачей. Во-первых, он довольно большой и содержит внушительных объемов документацию. Во-вторых — многие методы в нём «перегружены»: например, val() возвращает текстовое значение поля, а val(str) — записывает его и возвращает уже jQuery-объект.

К счастью, у документации к jQuery есть публичный API, который выдаёт описание всех методов в XML. Я написал парсер на node.js, который опрашивает API и преобразует XML в JSDoc, понятный для JSDT (и, надеюсь, другим IDE). Так что в случае выхода новой версии jQuery можно быстро перегенерировать всё документацию. Парсер я писал для себя и по-простому, он не поддерживает передачу параметров через командную строку, всё настраивается в main.js:

• Можно сгенерировать документацию для определённой версии jQuery (TARGET_VERSION).
• Можно сгенерировать описание в виде нескольких файлов. Это связано с особенностью JSDT. Как уже отмечалось ранее, в jQuery много «перегруженных» методов, и если их описать в одном JS-файле, то JSDT будет использовать только одно (самое последнее) описание. Однако если сохранить описание методов с одинаковым названием в разных файлах, то JSDT вполне неплохо покажет по ним code complete и документацию. Так что у вас есть выбор: при создании библиотеки jQuery добавить все файлы вида jquery-jsdoc-N.js (Eclipse JSDT) или же только jquery-jsdoс.js если ваша IDE способна прочитать описание с перегруженными методами.
• Можно переписать некоторые определения для более удобной работы с code complete (class_map, prefix_map). Например, так переписываются описания для Deferred и Promise объектов, чтобы можно было использовать их описание в JSDoc:

В описании есть ряд классов, которые можно использовать в JSDoc: __jQueryDeferred, __jQueryPromise и __jQueryEvent.

Пишем плагины к jQuery

Собственно, как писать плагины рассказывать нет смысла, это подробно описано в документации. Покажу лишь как сделать так, чтобы ваш плагин появился в code complete. А сделать это очень просто, достаточно методу плагина указать, что он является членом класса jQuery:

jQuery.extend(jQuery.fn, {
	/** @memberOf jQuery */
	myPlugin: function() {

	}
});

$('div').m // тут можно вызвать code complete

Поддержка Node.JS

Отдельно стоит упомянуть Node.JS, так как к модулям нужно обращаться не напрямую, а через функцию require():

var http = require('http');
http.createServer(function() {

});

То есть подсказки для модуля должны зависеть от того, какой аргумент передали в функцию require(). В целом, в JSDT эта ситуация решаема: нужно написать отдельный плагин в виде подключаемой библиотеки, который будет находить вызовы функции require(), смотреть на аргумент и возвращать виртуальный объект с необходимыми методами, и может быть я когда-нибудь напишу такую библиотеку. А пока будем довольствоваться малым: указывать тип модуля через JSDoc.

Все модули в моей документации описаны в виде классов Node{Name}Module, например: http → NodeHttpModule, util → NodeUtilModule. Поэтому для переменной, в которую записывается модуль, указываем через JSDoc нужный тип:

/** @type NodeHttpModule */
var http = require('http');
http. // вызываем code complete

Советы

В качестве заключения дам несколько советов, которые помогут вам в работе с JSDT:

• Не используйте фигурные скобки при указании типа переменной с помощью тэга @type — в некоторых случаях JSDT не сможет подцепить тип переменной. Лучше писать так: @type Array (вместо @type {Array}).
• При описании модуля тэг @memberOf moduleName достаточно указать только у одного свойства/метода в литерале, все остальные подцепятся автоматически.
• Если у вас в проекте есть непосредственно код библиотек (например, jQuery), то его лучше исключать из индекса, чтобы он не мешал работе code complete. Делается это так: заходите в настройки проекта Project > Properties > JavaScript > Include Path > Source. Разворачиваете папку с исходниками, двойной клик по фильтру Excluded и в диалоговом окне в секцию Exclusion patterns добавляете файлы, которые надо исключить.

Самая главная проблема всех редакторов для веб-разработки: они пишутся людьми, которые этой самой веб-разработкой не занимаются. Нет, они [программисты], конечно, могут на досуге собрать в своём редакторе сайтик-другой, но что делать тем, кто занимается веб-разработкой профессионально? Выход я вижу только один: взять хорошую платформу и доработать её до нужного состояния.

Как я уже написал, Aptana превратилось в некого монстра, с избыточным для не-Rails технологам функционалом. Поэтому в качестве платформы я выбрал более простой и, главное, лучше интегрированный в IDE плагин — Eclipse Web Tools Project.

Eclipse Web Tools Project

Как можно понять из названия, Eclipse WTP — это инструменты для веб-разработки, а не законченный проект (как Aptana, например). Цель этого проекта: создать платформу, на основе которой можно создавать другие, узкоспециализированные инструменты. Этот проект включает в себя редакторы для CSS, HTML, XML, XSL, JavaScript (отдельный большой проект под названием Eclipse JSDT; о нём расскажу в следующих частях). Проект частично включён практически во все официальные сборки Eclipse, но для начинающих пользователей рекомендую ставить Eclipse for JavaScript Web Developers, в ней есть всё.

Чтобы не пересказывать документацию, кратко приведу основные возможности:

• подсветка кода;
• сворачивание/разворачивание кусков кода (code folding);
• outline и quick outline (на последний рекомендую обратить особое внимание, по умолчанию вызывается через Ctrl+O или ⌘O);
• выделение границ тэгов (aka Balancing), смотрите в основном меню Edit > Expand Selection To;
• content assist по тэгам, атрибутам и значениям некоторых атрибутов;
• quick fix: переименование тэга (автоматически меняет открывающий и закрывающий тэги), обрамление тэгом;
• форматирование всего/выделенного кода;
• автоматическое закрытие тэгов.

Итак, с платформой определились, теперь нужно её настроить для комфортной работы.

Включаем поддержку HTML5 и CSS3

Eclipse WTP в версии 3.3 (которая доступна для Eclipse Indigo) появилась поддержка тэгов HTML5 и некоторых свойств CSS3. Однако сразу они не доступны, нужно немного пошаманить с проектом:

1. Открываем свойства проекта: Project > Properties.
2. Переходим на вкладку Project Facets и жмём на ссылку Convert to faceted form…
3. В появившемся окне выбираем фасет Static Web Module, жмём Apply.
4. Закрываем окно с настройками проекта.

Теперь в content assist будут доступны новые тэги и свойства. Если нет — снова открываем свойства проекта и идём на вкладку Web Content Settings, где настраиваем профили для HTML и CSS.

Включаем проверку правописания

Eclipse IDE с версии 3.4 (если мне не изменяет память) поддерживает проверку правописания, и по умолчанию доступен только английский словарь. Чтобы включить проверку правописания русского языка, делаем следующее:

1. Скачиваем и распаковываем русский словарь.
2. Открываем настройки Eclipse, идём в General > Editors > Text Editors > Spelling
3. В User defined dictionary выбираем распакованный ru.dict.
4. Ставим кодировку UTF-8

Всё, теперь, если редактор, которым вы пользуетесь, написан по гайдам Eclipse Platform, вам будет доступна проверка правописания.

Eclipse WTP Sugar

Самую большую ломку при переходе с Aptana на Eclipse WTP у меня вызывало отсутствие content assist для путей к файлам (например, в <script src="...">): приходилось писать все пути к файлам вручную, что сильно утомляло. Да и в Aptana он был не идеальным: работал только внутри атрибута src (<script src="...">, <img src="..."> и т.д.), но не работал внутри href (<link href="...">, <a href="...">) и уж тем более не в CSS (background url(...), @import url(...)).

Поэтому, потратив несколько месяцев на изучение Java и архитектуры Eclipse IDE, я написал свой content assist, который исправит этот недостаток, а заодно несколько других (о них чуть позже).

Свой проект я назвал Eclipse WTP Sugar, репозиторий для установки: http://media.chikuyonok.ru/eclipse/webdev/updates/, исходный код доступен на GitHub.

Плагин устанавливается очень просто, как и все остальные:

1. Идём в Help > Install New Software…
2. В качестве репозитория (поле Work with) вбиваем http://media.chikuyonok.ru/eclipse/webdev/updates/.
3. В появившемся списке плагинов выбираем необходимые и жмём кнопку Next.
4. Далее проходим стандартную процедуру установки (соглашаемся с лицензией, всё время жмём Next или Finish) и перезапускаем Eclipse.

Теперь, при нажатии Ctrl+пробел внутри атрибутов src и href можно увидеть список файлов:

Список файлов также выдаётся и в CSS, внутри функции url():

Список файлов по возможности фильтруется. Например, если его вызвал внутри тэга <script>, то увидите список файлов с расширением js, если внутри <link rel="stylesheet"> — файлы с расширением css.

Возвращаясь к разговору о том, что создатели программ для вёрстки сами толком сайты не верстают. Что если нужно использовать абсолютные пути для ссылок на файлы? По умолчанию считается, что абсолютный путь нужно резолвить относительно папки с проектом. Но почему никому не пришла в голову мысль, что веб-пространство проекта не всегда совпадает с корневой папкой проекта? В этом плагине проблема решена: в настройках проекта можно указать, относительно какой папки нужно резолвить абсолютные пути (Project > Properties > Document root):

Quick outline

Следующее, что хотелось изменить, так это quick outline: специальное контекстное окошко, которое показывает в компактном виде текущую структуру документа:

Эту структуру можно фильтровать, чтобы найти нужны элемент (поиск осуществляется с начала строки, можно использовать символы * и ?). Но, как видно из скриншота, в структуре выводятся только названия тэгов, что делает её малопригодной. WTP Sugar исправляет этот недостаток, выводя гораздо больше полезной информации, по которой, в том числе, можно искать:

Eclipse XV Browser

Не так давно я написал просмотрщик XML-файлов под названием XV Browser. В том посте я показал, что его можно использовать внутри Eclipse, однако не учёл один важный факт: работать это будет только если у вас Mac, а в качестве основного браузера используется Safari с установленным плагином XV

Eclipse XV Browser исправляет этот недостаток. Он представляет из себя обёртку для встроенного браузера (это может быть Webkit либо Mozilla, в зависимости от ваших настроек и версии Eclipse). С помощью этого плагина можно прросматривать любой сайт в виде XML-структуры (Window > Show View > Other… > XV Browser), либо открывать просматривать XML-файлы проекта (правый клик по файлу, Open With… > XV Browser).

Пожелания?

Если есьт какие-то идеи по улучшению плагинов — пишите в Issues проекта. Пока в планах:

• content assist по классам и идентификаторам, описанных в CSS;
• быстрый переход к CSS-определению класса или идентификатора;
• виджеты для редактирования CSS Gradients и CSS Box Shadow.

В следующей статье рассмотрим, как улучшить работу с Eclipse JSDT (JavaScript).

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

«Классическое» решение проблемы — прописать минимальную высоту блоку с названием, чтобы угадать некую среднюю величину, выше которой вряд ли что-то появится. Но у этого способа есть два недостатка: во-первых, практика показывает, что обязательно появится название, которое не впишется в отведённое пространство и развалит весь ряд. А во-вторых: при слишком коротких названиях будут появляться неприятные дыры между заголовком и блоком с ценой.

По сути, надо было придумать, как сделать так, чтобы блоки в одном ряду имели разное выравнивание по вертикали:

Такое расположение усложняется тем, что это не единственный режим просмотра: можно переключится на более крупный, двухколоночный режим. Причём желательно по-меньше трогать DOM-дерево — не делать специальных обёрток вокруг трёх или двух блоков, чтобы потом скриптом их перестраивать. Идеальный вариант — просто менять класс у контейнера и отдать всё изменение структуры на откуп CSS.

Как ни странно, но решение задачи нашлось, причём довольно элегантное.

Обычно такие последовательности блоков делаются самым очевидным образом: через float-элементы. Но этот способ нынче не в моде: все правильные ребята уже давно прочитали статью в блоге Мозиллы о том, как делать их через display: inline-block;.

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

<style type="text/css">
	.wrap, .h, .f {
		display: inline-block;
	}

	.h {
		background: red;
		height: 100px;
		padding: 0 10px;
	}

	.f {
		background: blue;
		height: 20px;
		padding: 0 10px;
		color: #fff;
	}
</style>

<span class="wrap">
	<span class="h">header</span>
	<span class="f">footer</span>
	<span class="h">header</span>
	<span class="f">footer</span>
</span>

Получим вот такой результат:

По умолчанию у всех блоков vertical-align: baseline, то есть вертикальное выравнивание по базовой линии (в данном случае, если проще — по последней строке текста). Если указать для .h{ vertical-align: top; } и для .f { vertical-align: bottom; }, то получим довольно интересное решение:

Блоки выровнены именно так, как нужно. Убеждаемся в правильности решения, изменив высоту одного из блоков:

Дальше всё просто: у шапки и подвала одинаковая и вполне определённая ширина, поэтому прописываем её каждому блоку, а подвал убираем из потока с помощью отрицательного margin’a:

Чтобы семантически объединить шапку и подвал, можно использовать любой элемент с display: inline. Итоговая версия доступна на тестовой странице.

Самое интересное, что этот код работает даже в IE6. Помним, что inline-block в этом браузере эмулируется с помощью display: inline и волшебного hasLayout, например, так: display: inline; zoom: 1;.

В этом решении важно помнить следующее:

1. Шапка и подвал в примере пересекаются, поэтому шапке нужно снизу давать отступ и подтягивать подвал любым доступным способом.
2. Между элементами конструкции не должно быть переводов строк и пробелов, иначе блоки визуально будут разделены.

В данном случае мне очень помогло то, что у подвала вполне предсказуемая высота, поэтому у шапки был добавлен снизу большой фиксированный отступ, чтобы блоки не перекрывались. Это решение полностью решило проблему и отображения, и переключения режимов. Можно пойти дальше и подключить CSS3 Media Queries, чтобы обладатели новых браузеров и больших мониторов могли видеть более трёх предложений в ряду, но это уже другая история. Думаю, читатели смогут найти более творческие и интересные применения этого небольшого трюка

Поэтому решил написать свой просмотрщик XML-файлов для браузеров на движке Webkit. Встречайте — XV:

Что умеет

• Сворачивание/разворачивание элементов. Для избавления от визуального шума соответствующие стрелочки появляются при наведении на элемент. Alt-клик по стрелке сворачивает/разворачивает все внутренние элементы.
• Outline для удобного обзора больших документов
• Поиск по названию или XPath. По умолчанию ищет вхождение подстроки в названии тэгов и атрибутов, если используются спецсимволы вроде ‘/’ или ‘[‘ то поиск автоматически переключается в XPath-режим.
• Режим Quick XPath — моя самая любимая фича. Зажмите клавишу Control (Mac) или Ctrl (PC) при наведении курсора на название элемента или атрибута чтобы войти в этот режим (появится специальный тултип). Нажимайте на клавишу Shift чтобы переключаться между доступными вариантами XPath, а затем просто перетаскивайте текущий элемент в текстовый редактор (используется drag’n’drop). Пользователи Google Chrome могут кликнуть по элементу, чтобы скопировать XPath в буфер обмена. Этот режим очень удобно использовать внутри IDE, например, вот так:

Скачать

• Расширение для Google Chrome
• Плагин для Safari (Mac) — обновлённый xmlview Марка

Можно также использовать и в Firefox как стандартный стиль для XML-файла, если скачать соответствующий XSL-файл:
<?xml-stylesheet type="text/xsl" href="xv-browser.xsl"?>.

Демонстрация

Посмотреть, как это выглядит, можно на тестовой страничке (хорошо работает в Safair/Chrome, в Opera и Firefox глючит drag’n’drop).

Исходный код доступен на GitHub: http://github.com/sergeche/xmlview/
Там же можно сообщения об ошибках (тестировал только на своих XML-файлах) и пожелания.

И мы сразу же начали получать жалобы о жутких тормозах на главной странице. На поиск и устранение проблем у меня ушло два дня. О том, как находились узкие места и будет сегодняшний рассказ. А заодно научимся пользоваться инструментами вроде Web Inspector’s Timeline (если вы их ещё не освоили).

Поиск проблемы

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

Самые большие проблемы наблюдались в Firefox: загрузка процессора на главной странице доходила до 70%. Поэтому я начал рассматривать скрипт таймера под микроскопом, а именно в Web Inspector, который по умолчанию входит в состав браузеров Safari и Chrome. Вообще, многие ребята довольно снисходительно относятся к этому инструменту, продолжая по привычке работать в Firebug’е, а зря. Лично для меня Web Inspector стал основным инструментом для отладки: выглядит он приятнее и содержит ряд полезных нововведений.

Исследуем узкие места

Так как сам скрипт таймера довольно простой, то не было смысла заниматься его профилированием — проблема явно где-то в reflow и repaint. Поэтому скрипт нужно исследовать через Timeline:

Полагаю, что многие читатели ещё ни разу не сталкивались с этим инструментом, поэтому принцип его работы и поиска проблем опишу в небольшом уроке. Стоит отметить, что Web Inspector в Chrome немного круче, чем в Safari, поэтому рекомендую пользоваться первым браузером.

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

Открываем шаблон в браузере и запускаем Web Inspector, вкладка Timeline. На странице есть красный квадратик и кнопка «Test». Чтобы начать исследование, нужно нажать на кнопку записи вкладки Timeline , а потом нажать на кнопку «Test» в основном окне браузера. Наш квадратик посинел и стал больше по высоте, а в Timeline записались следующие события:

Первые три записи относятся непосредственно к кнопке, которую нажали: применили псевдо-класс :active (Recalculate style), отобразили изменения на экране (Paint), вернули кнопку в исходное состояние, убрав :active (Recalculate style). После того, как пользователь отпустил кнопку мышки сработало событие click, и именно оно и всё, что ниже, нас будет интересовать.

Во время клика сработал следующий скрипт:

function test() {
	var el = document.getElementById('test');
	el.style.backgroundColor = 'blue';
	el.style.height = '100px';
}

Ничего особенного: просто получили ссылку на элемент и поменяли у него цвет фона и высоту. Этот процесс был отображён на временной шкале: пересчитали стили (Recalculate style), пересчитали геометрию объектов (Layout) и отобразили изменения (Paint).

Как видите, несмотря на то, что мы поменяли два СSS-свойства, пересчёт стилей произошёл всего один раз. Поменяем скрипт:

function test() {
	el.style.backgroundColor = 'blue';
	var height = el.offsetHeight;
	el.style.width = '100px';
}

Между присваиванием новых стилей мы решили получить высоту объекта. Но временная шкала сильно преобразилась:

Теперь у нас уже два события Recalculate style, а у самого события click появилась группировка (треугольник слева от жёлтой полоски), которая указывает, какие именно события произошли во время клика.

Этот небольшой пример указывает на две очень важные особенности браузеров — это откладывание перерисовки на момент выхода из функции (первый пример) и существование определённых свойств у элемента, которые принудительно вызывают пересчёт стилей (далее restyle; второй пример). О существовании особых свойств, вызывающих restyle, думаю, многие уже знали: это свойства вроде offsetLeft/Right/Width/Height, clientLeft/Right/Width/Height и так далее. Во втором примере, после установки свойства backgroundColor браузер пометил дерево элементов как требующего пересчёта стилей. А обращение к offsetHeight принудительно вызвало этот пересчёт. Затем мы установили свойство width, которое отложило пересчёт стилей, геометрии и отображения на момент выхода из потока JS-функций.

Отсюда первое правило: нужно стараться не смешивать получение и запись CSS-свойств. Лучше, например, сначала получить нужные свойства элемента, а затем присвоить новые.

Для любителей jQuery более красноречивым будет вот такой пример:

function test() {
	var e = $('#test');
	var width = e.css('width');
	if (width == '50px')
		e.css('width', '100px');

	var height = e.css('height');
	if (height == '50px')
		e.css('height', '100px');
}

Вот его шкала:

Как видите, помимо лишнего Recalculate style появился Layout (reflow), что сделало выполнение скрипта более медленным. Если немного оптимизировать, переместив получение высоты выше в коде:

function test() {
	var e = $('#test');
	var width = e.css('width'),
		height = e.css('height');

	if (width == '50px')
		e.css('width', '100px');

	if (height == '50px')
		e.css('height', '100px');
}

…получим совершенно иную картину:

Лишний Layout (помимо Recalculate style) объясняется тем, что jQuery каждый раз при получении CSS-свойств вызывал window.getComputedStyle(), который принудительно запускает reflow. Справедливости ради стоит отметить, что в функции jQuery.css() есть оптимизация, которая сначала проверяет наличие запрашиваемого свойства в element.style и если его там нет, вызывает window.getComputedStyle(). Но в любом случае, лучше всегда разделять чтение и изменение свойств.

Таймеры

Напомню, что я занимался оптимизацией таймеров, которых было несколько. И каждый таймер работает через свой setTimeout(). Посмотрим, что это означает на практике:

function test() {
	var el = document.getElementById('test');
	setTimeout(function(){
		el.style.backgroundColor = 'blue';
	}, 10);
	setTimeout(function(){
		el.style.width = '100px';
	}, 10);
}

У обоих таймеров одинаковый период ожидания и момент исполнения. На шкале видно, что после каждого таймера был запущен пересчёт стилей. Но в реальности момент исполнения будет далеко не всегда одинаковым. Поэтому поменяем задержку у последнего таймера — поставим 11 мс вместо 10 мс:

function test() {
	var el = document.getElementById('test');
	setTimeout(function(){
		el.style.backgroundColor = 'blue';
	}, 10);
	setTimeout(function(){
		el.style.width = '100px';
	}, 11);
}

И мы видим, что на шкале появился дополнительный repaint:

В итоге получалось, что из-за нескольких запущенных setTimeout() срабатывали ненужные перерисовки, которые пользователь всё равно не увидит, но процессор это нагружало прилично. Я переписал код таймеров таким образом, чтобы всё работало через один глобальный таймаут.

Итак, суммируя всё вышесказанное, для оптимизации я

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

В итоге в Firefox нагрузка на процессор снизилась… всего на 10%. Вообще, это было крайне странно: даже при наличии всего одного анимированного таймера на странице Firefox грузил процессор на 60%, при том что Webkit грузил всего на 5%. Нужно копать дальше.

Влияние вёрстки на производительность

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

Так как все restyle и reflow процессы я оптимизировал, проблема явно была где-то в repaint. Вспомнил, что в Firefox 3.5 появилось событие mozAfterRepaint, которое позволяет увидеть области, которые были перерисованы во время repaint. Для удобства было поставлено расширение Firebug Paint Events, которое позволяет отслеживать перерисовки экрана.

Чтобы описать всю бурю эмоций, которые я испытал после просмотра логов, предлагаю читателю посмотреть на скриншот, где указана область перерисовки во время работы всего одного таймера на странице:

Я специально оставил только 8 из 30 предложений, чтобы картинка не распирала страницу, но смысл, думаю, ясен: во время анимации даже одного таймера перерисовывалось примерно 90% страницы, 15 раз в секунду. И это при условии, что у цифр таймера указан position:absolute, а у их контейнера overflow:hidden. То есть сама анимация по определению никак не могла повлиять на области вне контейнера (на скриншоте обозначен синим прямоугольником), но перерисовывалась почти вся страница.

Около часа мне понадобилось на то, чтобы найти причину такого странного поведения. Ей оказалось… свойство float:left у одного из контейнеров. Как только я заменял его на float:none нагрузка на процессор падала ниже 10% (с float:left была около 60%).

Проблема проявляется стабильно, причём не только в Firefox, но и в Opera и IE8. Я сделал простую демку, где можно в живую увидеть эту проблему. В ней всего несколько блоков, однако у них указан box-shadow — очень тяжелое в плане нагрузки на процессор CSS-свойство. В правом верхнем углу есть кнопка, которая всего лишь переключает float у контейнера. Понаблюдайте за нагрузкой на процессор при разных состояниях кнопки, а также за областью перерисовки.

В общем виде проблему можно описать так:

Repaint срабатывает на контейнере самого дальнего родителя, у которого указан float:left|right.

Схематично это выглядит так:

Причём проблема не только во float. Я перепробовал различные варианты горизонатльной группировки блоков: display:inline-block, display:table-cell, таблицы и даже новомодные flex box — во всех случаях проблема оставалось. Помогало только абсолютное позиционирование боковых блоков.

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

***

Честно говоря, после таких браузерных крендебобелей на всякие пузомерки типа Peackeeper, которыми так хвастаются разработчики с каждым новым релизом своего браузера, без слёз смотреть не получается. Поэтому мой вам совет: заранее узнавайте о всех интерактивных элементах на странице, не увлекайтесь новым CSS3, продумывайте рост сайта заранее и пользуйтесь правильными инструментами для отладки производительности — тогда будет вам счастье и высокая производительность.

Если хотите узнать больше о профилировании производительности, очень рекомендую статью Стояна Стефанова на эту тему.

Как это делается сейчас? На сервере мы смотрим на заголовок User Agent и определяем, что это за браузер. Но этот заголовок можно легко подменить (причём необязательно это делать в самом браузере, это может сделать прокси-сервер), поэтому такая проверка совсем ненадёжна. На клиентской стороне у нас гораздо больше возможностей: мы можем не только проверить User Agent браузера, но и его возможности (например, поддержку определённых CSS и JS свойств), что даст нам более точные характеристики браузера.

Собственно, сама идея как раз заключается в том, чтобы скрестить эти два способа: определить с помощью CSS и JS характеристики браузера и в нужный момент сообщить их на сервер. Основа алгоритма — Chunked Transfer Encoding, позволяющий передать ответ (например, HTML-документ) не целиком, а кусками. Итак, сам алгоритм:

1. Когда пользователь запрашивает HTML-страницу, отдаём ему первый фрагмент (chunk), в котором содержится sniffing-код. После этого соединение удерживается на некоторое время, чтобы отдать второй фрагмент документа.
2. Браузер, получив первый фрагмент, тут же его парсит и пытается отобразить.
3. В этом первом фрагменте у нас sniffing-код, результатом работы которого является CSS-свойство background-image, применяемое к элементу <html>.
4. Путь к этой фоновой картинке является уникальным для каждого браузера и так уж получилось, что как только мы применили это свойство элементу, браузер открывает второе соединение и тут же пытается загрузить эту картинку.
5. Сервер, получив запрос к нашей «картинке» понимает, каким браузером мы зашли и отдаёт вторую часть ответа в первом соединении.
6. Если обращения к «картинке» не было (например, зашли поисковым роботом), то через какой-нибудь небольшой промежуток времени отдаём стандартный ответ.
7. После первого «вынюхивания» можно поставить куку, чтобы потом сразу отдавать нужный ответ.

В итоге получаем следующие преимущества:

• Нет никаких редиректов: ответ о типе браузера получаем в одном соединении (полезно для SEO).
• Очень сложно обмануть такой сниффер: можно до посинения менять строку User Agent, но результат останется прежним. Гугл сможет эффективней банить Оперу.
• Более сложные проверки: можно не просто определять название браузера, но и его возможности, благодаря CSS Media Queries.

Для желающих поэкспериментировать я написал демонстрацию этого подхода на node.js. К сожалению, у меня на VPS не хватает памяти, чтобы собрать node.js, поэтому предлагаю читателю самому его установить и проверить у себя. Если кто выложит это в онлайн — буду премного благодарен. Выложили: http://tbms.ru:8126/ (спасибо Николаю Митину).

Полезные уроки

Пока писал эту демонстрацию, вынес для себя много ценной информации:

1. Первый чанк должен быть достаточно большим, чтобы все браузеры смогли его применить. Самый большой лимит — у движка Webkit: около 2 КБ. Поэтому приходится «добивать» первый фрагмент пробелами, чтобы всё работало как надо.
2. Webkit очень плохо ведёт себя при переопределении CSS-свойств. Например:

   html { background-image:url(image1.png); }
   html { background-image:url(image2.png); }
   		

   В этом случае Webkit (и десктопный, и мобильный) загрузит обе картинки, хотя понятно, что нужна только последняя. Это ещё одно подтверждение, что мобильные версии сайта лучше делать отдельным проектом, а не вставлять через CSS Media Queries. Иначе попытки сократить траффик заменой больших фоновых картинок на маленькие приведёт к обратному эффекту. Хотя тут нужно больше исследований, возможно, это издержки работы с локальным сервером.

3. Firefox не отработает первый чанк до тех пор, пока не получит элемент <body>. Это довольно серьёзный недостаток в том случае, если вы захотите выдавать уникальные стили и скрипты для браузера в секции <head>. С другой стороны, если послать <script>alert(1)</script>, то чанк отработает нормально, даже без <body>. Что наталкивает на мысль о существовании неких триггеров, которые заставят браузер сделать то, что нам нужно, осталось только найти наиболее безопасный.

Повторюсь, что это только идея, а не призыв к действию. Буду рад, если кто-то на её основе сделает что-то крутое и интересное.

Проект называется XSL Tracer. Его задача заключается в том, чтобы ответить на простой вопрос: откуда после XSL-трансформации пришёл тот или иной элемент? Как это работает можно увидеть на демо-странице. Там отображается результат XSL-преобразования — обычный HTML-документ. Кликнув по любому элементу можно получить подробную информацию о нём:

• XSL: шаблон, где выводится элемент.
• Context: контекстный XML (на который сработал матч, в случае xsl:apply-templates). Сам элемент выводится урезанным (только 10 внутренних тэгов), чтобы в случае, если это будет корневой элемент, браузер не умер в муках (да и толку от полной структуры никакого).
• Source: место в шаблоне, где непосредственно генерируется выбранный элемент. Очень удобно в случае, если делаете сopy-of результатирующей структуры (в примере это html-код, заданный внтутри переменной).
• Call stack: стэк вызовов apply-template/call-template/apply-imports, через который дошли до вызова текущего шаблона
• Inner calls: список внутренних вызовов шаблонов, которые по каким-то причинам нельзя отобразить (по крайней мере пока) в документе. Например, вызов шаблонов, выдающих атрибуты для выбранного элемента, или его текстовое содержимое. Список отображается под Call stack, и только в том случае, если такие вызовы есть.

Демка нормально работает в Safari/Firefox/Chrome, Opera жутко тормозит на больших документах, а в IE даже не открывал.

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

Как это работает

Проект состоит из двух частей: бэкэнд и фронтэнд.

На бэкэнде используется Saxon 6.5 (пока эта версия, так как в 9.2 лично у меня вылезло куча проблем с EXSLT). У него есть встроенный механизм трассировки, который по умолчанию генерирует результат в виде XML (такой файл на реальных проектах вырастает до нескольких мегабайт). Я написал свой трассировочный класс, который выводит данные в более компактном и лёгком JSON-формате, а также дополнительные данные вроде списка используемых в трансформации XSL и XML (подключённых через document()) документов. А также он делает дополнительные штуки вроде резолвинга result-tree фрагментов при вызове xsl:copy-of.

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

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

Как запускать

1. Должна быть установлена Java (версия особо не важна).
2. Скачиваем Saxon 6.5
3. Скачиваем трэйсер
4. Генерируем трассировку вот такой командой в консоли:

java -classpath /path/to/tracer.jar:/path/to/saxon.jar ru.imobilco.XSLTracer -to /path/to/trace-result.html /path/to/input.xml /path/to/template.xsl

В случае успешной работы трэйсера сгенерируется файл trace-result.html, который можно сразу открывать в браузере (CSS и JS берутся с моего сервера). Если возникла ошибка во время трансформа, то файл будет сгенерирован, но вместо документа увидите нормальное сообщение об ошибке. В случае ошибки работы Java, увидите сообщение в консоли.

Надо помнить, что Saxon очень чувствителен ко всяким всяким отхождениям от спецификации, поэтому то, что работало в Xalan/libxsl/где-то ещё может не сработать в Saxon. Но исправления, как правило, довольно мелкие и незначительные.

Онлайн-версия

Мой коллега Лёха Баранов написал сервлет, который позволяет запускать через веб, передавая ссылки на XML и XSL файлы. Для него был заведён специальный проект xmltools.ru. Работает просто: указываете ссылки на файлы и, если нужно, данные для http-авторизации. Далее сам трансформ находит все зависимые файлы, скачивает их и делает трансформ.

Но с онлайн-версией не так всё просто. В частности, когда результат отдаётся фронтэнду, он тоже начинает скачивать внешние файлы через аякс. И, как вы уже, наверно, догадались, включается ограничение Same-Origin Policy, которое не позволяет загружать данные с другого домена. Вариантов решения два: либо вы свой сервер настраиваете на cross-domain ajax, либо используете xmltools.ru как сервис, запрашивая трансформ через какой-нибудь php/python/ruby скрипт, отдавая результат трассировки со своего домена.

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

$.post('my-url.php', $('form#my-form').serialize());

Но это минимальный код; код из серии «создаём свой блог/цмс за 5 минут», которым так любят заманивать создатели всяких движков и фреймворков. А что нужно сделать, чтобы такая форма стала удобной и понятной для конечного пользователя, то есть «человеческой»?

Недавно мы запустили новый скидочный проект BigBuzzy. Так как на рынке уже существует масса подобных проектов, единственный способ выделиться из толпы — это сделать проект очень удобным для пользователя, как с концептуальной точки зрения (не надо ждать, пока наберётся определённая группа; удобные способы оплаты), так и с технологической.

Одна из фич проекта — отправка купленного купона себе на телефон по СМС. Так как на месте проведения акции нужно предъявить только номер купона, нет особого смысла печатать его на бумаге, можно показать и с телефона. Увидеть форму в действии можно на бигбаззи, купив 10 купонов на этой странице. В этой форме как раз два поля: код и номер телефона. Посмотрим, что можно в ней улучшить.

Алгоритм работы

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

А что делать, если пользователь уже ввёл номер при отправке первого купона и хочет отправить второй? Логично, что он захочет отправить купон на тот же самый номер. Нужно ли в этом случае показывать форму? Решаем, что нужно. Во-первых, пользователь может захотеть отправить купон своему другу в качестве подарка или этот друг только что позвонил и попросил выручить, докупив ещё два купона на боулинг. Заставлять пользователя идти в Личный кабинет и менять там номер телефона как-то уж совсем неправильно. Во-вторых, появляющаяся форма будет своеобразным подтверждением действия (вдруг он случайно нажал на эту кнопку?). Поэтому на нажатие конпки будем запускать анимацию появления формы, а повторное нажатие на эту же кнопку отправить данные на сервер:

$(document.body).delegate('.coupon-button', 'click', function(/* Event */ evt) {
	var elem = $(this);
	if (elem.hasClass('coupon-button-sms')) {
		var coupon = elem.closest('.coupon');
		if (!coupon.length)
			return;

		if (!coupon.hasClass('coupon-sms-mode')) {
			// переключаем купон в режим отправки СМС
			switchSMSMode(coupon);
		} else  {
			// пытаемся отправить данные на сервер
			tryToSendSMS(coupon);
		}
	}
});

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

$(document.body).delegate('.coupon-button', 'click', function(/* Event */ evt) {
	var elem = $(this),
		is_animating = false;

	if (elem.hasClass('coupon-button-sms')) {
		var coupon = elem.closest('.coupon');
		if (!coupon.length || is_animating)
			return;

		if (!coupon.hasClass('coupon-sms-mode')) {
			// переключаем купон в режим отправки СМС
			is_animating = true;
			switchSMSMode(coupon, function(){
				is_animating = false;
			});
		} else  {
			// пытаемся отправить данные на сервер
			tryToSendSMS(coupon);
		}
	}
});

Ввод данных

Форму мы показали, теперь нужно упростить пользователю ввод данных. Тут надо помнить, что существует множество моделей поведения пользователя. Кто-то быстро введёт код и переключится табом на следующее поле, кто-то будет минуту набирать три цифры и схватиться за мышку, чтобы переключиться на следующее поле, кто-то будет ожидать, что введённая последовательность из 10 цифр автоматически распределиться между полями. Нужно постараться удовлетворить максимальное количество пользователей. Поэтому будем следить за полем «код», и когда там будет 3 цифры — автоматически перебросим фокус на поле с номером:

$('.phone-code').keyup(function(){
	if (this.value.length == 3)
		$(this).next('.phone-num').focus();
});

Так делают многие и так делать ни в коем случае нельзя. Если пользователь допустил ошибку в коде, то попытка исправить её используя только клавиатуру превратиться в сущий ад: например, нажатие на стрелки клавиатуры всегда будет приводить к перебросу фокуса, потому что сработает событие событие keyup, а в поле уже будет 3 символа. Чтобы сделать поведение формы более естественным, нужно следить за вводом данных: перебрасывать фокус будем только если в предыдущем нажатии на кнопку (last_length) было меньше символов, чем в этом нажатии, количество символов равно трём и каретка находится в самом конце поля:

$('.phone-code').bind('keyup change', function(/* Event */ evt) {
	var field = $(evt.target),
		last_length = field.data('last_length') || 0,
		cur_length = field.val().length,
		max_length = parseInt(field.attr('maxlength')) || 3,
		selection = getSelectionRange(field[0]);

	if (cur_length > last_length && cur_length == max_length && selection && selection.start == cur_length) {
		field.next('.phone-number').focus();
	}

	field.data('last_length', cur_length);
});

function getSelectionRange(elem) {
	if ('selectionStart' in elem) { // W3C's DOM
		return {
			start: elem.selectionStart,
			end: elem.selectionEnd
		};
	} else if (document.selection) { // IE
		elem.focus();

		var range = document.selection.createRange(),
			content = elem.value;

		if (range === null) {
			return {
				start: 0,
				end: content.length
			};
		}

		var re = elem.createTextRange();
		var rc = re.duplicate();
		re.moveToBookmark(range.getBookmark());
		rc.setEndPoint('EndToStart', re);

		return {
			start: rc.text.length,
			end: rc.text.length + range.text.length
		};
	} else {
		return null;
	}
}

Но тут возникает ещё одна проблема. Далеко не каждый пользователь догадается, что при заполнении поля с кодом фокус перекинется на следующее поле. Он может не глядя на монитор набрать 3 цифры, нажать на таб и набрать ещё 7 цифр. В этом случае наша «помощь» только помешает пользователю, потому что фокус будет где-то совершенно в другом месте. Чтобы такого не случилось, нужно временно заблокировать нажатие на таб на поле с номером телефона после того, как фокус был автоматически переброшен:

$('.phone-code').bind('keyup change', function(/* Event */ evt) {
	var field = $(evt.target),
		last_length = field.data('last_length') || 0,
		cur_length = field.val().length,
		max_length = parseInt(field.attr('maxlength')) || 3,
		selection = getSelectionRange(field[0]);

	if (cur_length > last_length && cur_length == max_length && selection && selection.start == cur_length) {
		var num_field = field.next('.phone-number');

		// временно блокируем Tab на следующем поле
		num_field.data('tab_locked', true);
		setTimeout(function() {
			num_field.data('tab_locked', false);
		}, 1000);

		num_field.focus();
	}

	field.data('last_length', cur_length);
});

$('.phone-number').bind('keydown keyup keypress', function(/* Event */ evt) {
	var field = $(evt.target);
	if (field.data('tab_locked') === true && evt.keyCode == 9) {
		// блокируем работу клавиши Tab
		evt.preventDefault();
	}
});

Валидация данных

Перед отправкой данных на сервер нужно сделать простую валидацию данных, чтобы убедиться, что введённые данные похожи на номер телефона. Если нет — то намекнём об этом пользователю.

Вводить жёсткий формат записи числовых данных вроде номера телефона или кредитной карты — первый признак полового бессилия разработчика. Для номера телефона нам нужно 10 цифр (код + сам номер), и не важно, написаны цифры слитно или разделены пробелами или дефисами. Пользователь должен написать номер в привычном ему формате, чтобы легче было проверять правильность. Поэтому при валидации удалим из полей все не числовые символы и проверим длину того, что осталось:

function validatePhoneNumber(coupon) {
	coupon = $(coupon);

	var re_num = /[^0-9]/g,
		phone_code = coupon.find('.phone-code'),
		phone_num = coupon.find('.phone-number'),
		is_valid_code = phone_code.val().replace(re_num, '').length == 3,
		is_valid_num = phone_num.val().replace(re_num, '').length == 7;

	if (!is_valid_code)
		blinkField(phone_code);
	if (!is_valid_num)
		blinkField(phone_num);

	return is_valid_code && is_valid_num;
}

Если введённые данные не верны, то мы должны сообщить об этом пользователю. Пространство у нас очень ограничено, поэтому будем «моргать» полем, указывая, что там что-то не так. Функция добавляет и удаляет определённый класс у элемента через заданный промежуток времени, в CSS укажем этому классу красный цвет:

function blinkField(fld) {
	fld = $(fld);
	if (fld.data('blink_timer'))
		clearInterval(fld.data('blink_timer'));

	var blink_count = 6;

	fld.data('blink_timer', setInterval(function() {
		fld.toggleClass('coupon-field-warning');
		if (blink_count-- < 0) {
			fld.removeClass('coupon-field-warning');
			clearInterval(fld.data('blink_timer'));
		}
	}, 100));
}

Отправка данных

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

Кто-то решает эту задачу так: показывает индикатор, ждёт определённое время и уже после этого отправляет запрос на сервер, а после получения ответа прячет индикатор. Так делать не правильно: в случае с медленным интернетом таймаут слишком сильно увеличивается; сам запрос мог бы запросто отработать за то время, пока показывается индикатор. Поэтому мы устроим небольшую гонку: что последним закончится выполняться — таймер индикатора или запрос на сервер — то и покажет фидбэк пользователю:

function sendSMSRequest(coupon) {
	coupon = $(coupon);
	var phone_code = coupon.find('.phone-code').val(),
		phone_num = coupon.find('.phone-number').val();

	coupon.addClass('coupon-preloader');
	// запускаем индикатор
	preloader.start();

	// два условия отображения фидбэка: закончился таймер и пришёл ответ от сервера
	var timer_reached = false,
		response_received = false;

	function checkStatus() {
		if (timer_reached && response_received) {
			// останавливаем индикатор
			preloader.start();
			coupon.removeClass('coupon-preloader');

			// прячем форму с номером телефона
			switchSMSMode(coupon);
		}
	}

	// устраиваем гонку между таймером и запросом
	setTimeout(function() {
		timer_reached = true;
		checkStatus();
	}, 1000);

	$.get(sms_url, {
		id: coupon.attr('id'),
		action: 'send_sms',
		phone: phone_code + phone_num
	}, function(data) {
		response_received = true;
		checkStatus();
	}, 'json');
}

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

<textarea>, да и веб-технологии в целом привлекают меня своей простотой, доступностью и возможностью сделать так, как нужно мне. Есть Zen Coding, который позволяет быстро и удобно работать с большим объёмом XHTML-данных, но для пущего удобства не хватает автодополнения кода. Поиск в интернете не дал никаких вменяемых результатов, поэтому решил написать свой:

Проверить автодополнение можно на тестовой странице. Попробуйте написать несколько английских слов, начинающихся на «a» (awesome, animal, amazing). Должно работать везде, включая IE6.

Само по себе автодополнение, по большому счёту, практически бесполезно: непонятно, в какой момент какие данные нужно показывать. Поэтому решение представляет из себя несколько отдельных классов, каждый из которых можно переопределить, расширить и дополнить. За основу была взята архитектура автодополнения для Eclipse IDE, поэтому ряд классов и методов называются одинаково.

• TextViewer — по сути, обёртка для <textarea>. Основное предназначение: дать удобный интерфейс для получения содержимого элемента. Один из основных методов — getCharacterCoords(char_ix), возвращает координаты для определённого символа. Метод возвращает объект со свойствами x и y в пикселях, отсчёт идёт от левого верхнего угла <textarea> до левого верхнего угла нужного символа. Метод getAbsoluteCharacterCoords(char_ix) возвращает то же самое, только относительно offsetParent. Как не трудно догадаться, этот класс можно переписать для работы с content-editable блоком, и у вас будет автодополнение для более серьёзного редактора.
• ContentAssistProcessor — процессор, который высчитывает и предлагает список дополнений. По умолчанию ищет левую и правую границу английского слова (см. метод isAllowedChar), ищет префикс (от левой границы слова до каретки) и предлагет по этому префиксу список дополнений.
• CompletionProposal — предложение для автодополнения. Главный метод — apply(), который применяет текущее предложение к TextViewer-объекту.
• ContentAssist – основной класс. Связывает между собой TextViewer и ContentAssistProcessor, а также управляет всплывающим окном с подсказками.
• tx_utils — набор всяких DOM-утилит.

Для добавления поддержки автодополнения для <textarea> нужно инициализировать все эти классы:

var viewer = new TextViewer(document.getElementById('my-textarea'));
var processor = new ContentAssistProcessor(['word1', 'word2', 'word3']);
var content_assist = new ContentAssist(viewer, processor);

Для удобства есть класс BasicContentAssist, который делает всё то же самое для простых случаев (автодополнение по фиксированному словарю):

new BasicContentAssist(document.getElementById('my-textarea'), ['word1', 'word2', 'word3']);

У класса ContentAssistProcessor есть метод completitionProposalFactory, который должен возвращать объект класса CompletionProposal. Внешний вид попапа с предложениями был нагло позаимствован из редактора Espresso и полностью управляется через CSS. Окошко с предложениями можно вызвать принудительно по Ctrl+Space (не работает в Опере и немного тупит в Файерфоксе) либо по Alt+Space (хвала разработчикам Оперы: это тоже не работает, по крайней мере на Маке) и заменить текущее слово (зависит от позиции каретки).

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

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