• Ambilight для тэга video

    В некоторых топовых моделях телевизоров Philips есть такая прикольная штука, как Ambilight. По сути, это светодиодная подсветка телевизора, которая меняет цвет в зависимости от цвета картинки. Смотреть кино на таком телевизоре — одно удовольствие.

    На флэше уже есть реализации такой подсветки, ну а чем мы — фронтовики — хуже? Дабы в очередной раз разобраться, на что способны современные браузеры, на свет появился очередной эксперимент:

    Ambilight для тэга <video> (Firefox 3.5, Opera 10.5, Safari 4, Google Chrome 4)

    Далее рассмотрим, как это было сделано.

    Алгоритм

    Прежде, чем начать что-то писать, нужно составить алгоритм, по которому будет работать наша подсветка.

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

    Исходя из этого описания, нам нужно проделать следующее: определить цвет каждого диода для текущего кадра и отрисовать его свечение. Что ж, приступим.

    Определяем цвет диода

    Для удобства предположим, что в нашем «телевизоре» всего по 5 светодиодов с каждой стороны. Соответственно, нужно взять фрагмент кадра, разделить его на области по количеству диодов и найти усреднённый цвет в каждой области — это и будут цвета подсветки:

    get-color

    Чтобы получить изображение текущего видео-кадра, достаточно отрисовать его в <canvas> через метод drawImage():

    var canvas = document.createElement('canvas'),
    	video = document.getElementsByTagName('video')[0],
    	ctx = canvas.getContext('2d');
    
    // обязательно выставляем размер холста
    canvas.width = video.width;
    canvas.height = video.height;
    
    // рисуем кадр
    ctx.drawImage(video, 0, 0, video.width, video.height);
    

    Текущий кадр получили, теперь нужно узнать, какого цвета пиксели сбоку изображения. Для этого воспользуемся методом getImageData():

    /** Ширина области, которую будем анализировать */
    var block_width = 50;
    
    var pixels = ctx.getImageData(0, 0, block_width, canvas.height);
    

    В объекте pixels есть свойство data, в котором содержатся цвета всех пикселей. Причём хранятся они в немного необычном формате: это массив RGBA-компонетнов всех пикселей. К примеру, чтобы узнать цвет и прозрачность первого пикселя, нужно взять первые 4 элемента массива data, второго пикселя — следующие 4 и так далее:

    var pixel1 = {
    	r: pixels.data[0],
    	g: pixels.data[1],
    	b: pixels.data[2],
    	a: pixels.data[3]
    };
    
    var pixel2 = {
    	r: pixels.data[4],
    	g: pixels.data[5],
    	b: pixels.data[6],
    	a: pixels.data[7]
    };
    

    Нам нужно разделить все полученные пиксели на 5 групп (по количеству светодиодов, которое мы выбрали ранее) и проанализировать каждую группу по очереди:

    function getMidColors() {
    	var width = canvas.width,
    		height = canvas.height,
    		lamps = 5, //количество светодиодов
    		block_width = 50, // ширина анализируемой области
    		block_height = Math.ceil(height / lamps), // высота анализируемого блока
    		pxl = block_width * block_height * 4, // сколько всего RGBA-компонентов в одной области
    		result = [],
    
    		img_data = ctx.getImageData(0, 0, block_width, h),
    		total = img_data.data.length;
    
    	for (var i = 0; i < lamps; i++) {
    		var from = i * width * block_width;
    		result.push( calcMidColor(img_data.data, i * pxl, Math.min((i + 1) * pxl, total_pixels - 1)) );
    	}
    
    	return result;
    }
    

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

    function calcMidColor(data, from, to) {
    	var result = [0, 0, 0];
    	var total_pixels = (to - from) / 4;
    
    	for (var i = from; i <= to; i += 4) {
    		result[0] += data[i];
    		result[1] += data[i + 1];
    		result[2] += data[i + 2];
    	}
    
    	result[0] = Math.round(result[0] / total_pixels);
    	result[1] = Math.round(result[1] / total_pixels);
    	result[2] = Math.round(result[2] / total_pixels);
    
    	return result;
    }
    

    Итак, мы получили цвета для светодиодов, но они слишком тусклые: ведь диоды светят очень ярко чтобы добиться достаточного уровня свечения. Нужно увеличить яркость цветов, а также увеличить насыщенность, чтобы добавить глубины свечению. Для этих целей очень удобно пользоваться цветовой моделью HSV — hue, saturation, value, — достаточно домножить два последних компонента на некий коэффициент. Но цвета у нас хранятся в модели RGB, поэтому сначала конвертируем цвет в HSV, увеличиваем яркость и насыщенность, а затем обратно конвертируем в RGB (формулы конвертирования RGB→HSV и обратно легко находятся в интернетах):

    function adjustColor(color) {
    	color = rgb2hsv(color);
    	color[1] = Math.min(100, color[1] * 1.4); // насыщенность
    	color[2] = Math.min(100, color[2] * 2.7); // яркость
    	return hsv2rgb(color);
    }
    

    Рисуем свечение

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

    Градиент рисуется просто: сначала создаём его с помощью createLinearGradient(), а потом добавляем цвета через addColorStop() и отрисовываем его:

    // для свечения создаём новый холст
    var light_canvas = document.createElement('canvas'),
    	light_ctx = light_canvas.getContext('2d');
    
    light_canvas.width = 200;
    light_canvas.height = 200;
    
    var midcolors = getMidColors(), // полчаем усреднённые цвета
    
    	grd = ctx.createLinearGradient(0, 0, 0, canvas.height); // градиент
    
    for (var i = 0, il = midcolors.length; i < il; i++) {
    	grd.addColorStop(i / il, 'rgb(' + adjustColor(midcolors[i]).join(',') + ')');
    }
    
    // рисуем градиент
    light_ctx.fillStyle = grd;
    light_ctx.fillRect(0, 0, light_canvas.width, light_canvas.height);
    

    Получим что-то вроде этого:

    gradient

    Маска

    Маску мы нарисуем в фотошопе. Есть замечательный фильтр Lightning Effects (Filters→Render→ Lightning Effects…), который позволяет создавать источники света. Заливаем слой белым цветом и вызываем этот фильтр примерно с такими настройками:

    lightning

    Получим вот такое световое пятно:

    spot

    Меняем режим наложения на Lighten, дублируем, крутим, меняем масштаб, играемся с прозрачностью, правим уровни и получаем вот такой результат:
    spot-grid

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

    result

    Но самое главное — мы легко сможем менять внешний вид и интенсивность свечения, не прибегая к программированию.

    Свечение для левой стороны готово, осталось проделать то же самое для правой стороны, добавить плавную смену подсветок и написать контроллер, который с определённым интервалом будет эту подсветку обновлять. Расписывать это — долго и нудно, проще посмотреть исходник.

    UPD: как показал эксперимент, далеко не у всех нормально работает HD-видео (изначально размер ролика был 1280×544), снижение разрешения до 592×256 решило проблему.

    Метки: , , ,
  • Улучшаем text-align: justify

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

    Не люб­лю я вос­крес­ные ве­че­ра. Как бы объ­яс­нить… все, что с ни­ми свя­за­но, то есть са­му об­ста­нов­ку вос­крес­но­го ве­че­ра, я не люб­лю. С при­бли­же­ни­ем вос­крес­но­го ве­че­ра у ме­ня обя­за­тель­но на­чи­на­ет дер­гать в го­ло­ве. Ког­да силь­нее, ког­да сла­бее. Но дер­га­ет обя­за­тель­но. Внут­ри вис­ков, в сан­ти­мет­ре или двух от ко­жи, дер­га­ет с обе­их сто­рон так, как буд­то что-то тя­нет мяг­кий бе­лый сгус­ток пло­ти на­ру­жу. Ощу­ще­ние, что из се­ре­ди­ны вис­ка вы­ле­за­ет не­ви­ди­мая нить, а кто-то из­да­ле­ка, схва­тив за са­мый кон­чик, по­ти­хонь­ку дер­га­ет за нее. Мне не осо­бен­но-то и боль­но. Я бы не уди­вил­ся, если бы бы­ло боль­но, но, как ни стран­но, не боль­но. Буд­то глу­бо­ко вве­ли длин­ную иг­лу в оне­мев­шее от нар­ко­за мес­то.

    Но в случае с переносами текст можно заметно улучшить. Достаточно всего лишь уменьшить расстояние между словами с помощью CSS-свойства word-spacing, выставив минимально допустимое расстояние. Важно помнить, что в word-spacing указывается не само расстояние, а его отклонение от стандартного значения: word-spacing: 0 — стандартное расстояние, word-spacing: 10px; — стандартное расстояние + 10 пикселей.

    Немного подтянем слова друг к другу:

    p {
    	text-align: justify;
    	word-spacing: -0.3ex;
    }
    

    …и текст выглядит заметно лучше:

    Было

    Не люб­лю я вос­крес­ные ве­че­ра. Как бы объ­яс­нить… все, что с ни­ми свя­за­но, то есть са­му об­ста­нов­ку вос­крес­но­го ве­че­ра, я не люб­лю. С при­бли­же­ни­ем вос­крес­но­го ве­че­ра у ме­ня обя­за­тель­но на­чи­на­ет дер­гать в го­ло­ве. Ког­да силь­нее, ког­да сла­бее. Но дер­га­ет обя­за­тель­но. Внут­ри вис­ков, в сан­ти­мет­ре или двух от ко­жи, дер­га­ет с обе­их сто­рон так, как буд­то что-то тя­нет мяг­кий бе­лый сгус­ток пло­ти на­ру­жу. Ощу­ще­ние, что из се­ре­ди­ны вис­ка вы­ле­за­ет не­ви­ди­мая нить, а кто-то из­да­ле­ка, схва­тив за са­мый кон­чик, по­ти­хонь­ку дер­га­ет за нее. Мне не осо­бен­но-то и боль­но. Я бы не уди­вил­ся, если бы бы­ло боль­но, но, как ни стран­но, не боль­но. Буд­то глу­бо­ко вве­ли длин­ную иг­лу в оне­мев­шее от нар­ко­за мес­то.

    Стало

    Не люб­лю я вос­крес­ные ве­че­ра. Как бы объ­яс­нить… все, что с ни­ми свя­за­но, то есть са­му об­ста­нов­ку вос­крес­но­го ве­че­ра, я не люб­лю. С при­бли­же­ни­ем вос­крес­но­го ве­че­ра у ме­ня обя­за­тель­но на­чи­на­ет дер­гать в го­ло­ве. Ког­да силь­нее, ког­да сла­бее. Но дер­га­ет обя­за­тель­но. Внут­ри вис­ков, в сан­ти­мет­ре или двух от ко­жи, дер­га­ет с обе­их сто­рон так, как буд­то что-то тя­нет мяг­кий бе­лый сгус­ток пло­ти на­ру­жу. Ощу­ще­ние, что из се­ре­ди­ны вис­ка вы­ле­за­ет не­ви­ди­мая нить, а кто-то из­да­ле­ка, схва­тив за са­мый кон­чик, по­ти­хонь­ку дер­га­ет за нее. Мне не осо­бен­но-то и боль­но. Я бы не уди­вил­ся, если бы бы­ло боль­но, но, как ни стран­но, не боль­но. Буд­то глу­бо­ко вве­ли длин­ную иг­лу в оне­мев­шее от нар­ко­за мес­то.

  • Data:URL средствами браузера

    Думаю, зачем нужен data:url объяснять не стоит. Несмотря на проблемы с применением в IE, data:url незаменим, когда нужно отдавать HTML-страницу в виде одного файла (очень удобно такие файлы кэшировать в приложениях). Мне в последнее время приходится с ним довольно много работать и я был озадачен поиском хорошего инструмента, который смог бы легко кодировать графические файлы в base64. Критерии к инструменту следующие:

    • drag’n’drop;
    • возможность конвертации сразу нескольких файлов;
    • удобное копирование конечного результата;
    • должен работать на Маке;
    • няшный интерфейс с прЕкольными анимашками )))))))

    Беглый поиск в интернете удовлетворительных результатов не дал. Есть утилитка от Sveinbjorn Thordarson, которой я пользовался раньше, но она очень неудобная: принимает только по одному файлу, а результат нужно вычленять из <img>-тэга (там есть ссылка на маковский дроплет, который у меня не завёлся). Duris смущает тем, что требует готовую страницу, доступную где-то в интернете (слишком сложно для преобразования 2—3 файлов).

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

    Как оказалось, вполне себе могут. Вот что у меня получилось. Работает, правда, не везде: только Firefox 3.6, Safari 4, последний Google Chrome (только Windows-версия). Для Safari и Chrome нужно сначала скачать себе эту страничку и запустить её локально (почему так узнаете, дочитав статью). Несмотря на такие ограничения, поддержки этих браузеров вполне достаточно для современного веб-разработчика.

    Дальше будет много текста про то, как создавался этот сервис.

    Начало

    Помимо выполнения сугубо утилитарных функций (кодирование бинарного изображения в base64 налету), этот сервис в первую очередь был плацдармом для обкатки новых браузерных технологий, о которых все говорят, но толком не используют. В частности, это CSS Transforms, CSS Transitions и CSS Animations. Поэтому работа была более исследовательской, нежели практической. В качестве инструментария я выбрал jQuery для рутинных DOM-операций и свой jTweener для анимаций (его очень легко адаптировать под любые CSS-свойства). Итак, начнём.

    Firefox

    В новом Firefox 3.6 появилось много нововведений, одно из которых — поддержка drag’n’drop. Причём таскать и бросать можно не только локальные блоки на веб-странице, но и внешние файлы. Перетаскиваемые файлы можно «поймать» с помощью JS и что-нибудь с ними сделать, не перезагружая страницу. Для этих целей существуют специальные объекты вроде Clipboard и FileReader, позволяюще получить и тут же прочитать файлы.

    Вообще, в Firefox 3.6 задача кодирования перетаскиваемых файлов в base64 решается элементарно: вешаем на окно обработчик события drop, в котором из объекта события достаём список перетаскиваемых файлов и читаем их с помощью FileReader. Примерный код решения:

    function handleFiles(evt) {
    	// запрещаем бразеру открывать перетаскиваемые файлы
    	evt.stopPropagation();
    	evt.preventDefault();
    
    	// список перетаскиваемых файлов
    	var files = evt.dataTransfer.files;
    
    	// читаем файлы
    	for(var i = 0; i < files.length; i++) {
    		var reader = new FileReader();
    		reader.onloadend = function(e) {
    			// в e.target.result содержится изображение в формате data:url
    			console.log(e.target.result);
    		};
    		reader.readAsDataURL(files[i]);
    	}
    }
    
    document.addEventListener('drop', handleFiles, false);
    

    Обратите внимание вот на что: если используете jQuery, то привязать событие drop через $(document).bind('drop', handleFiles); не получится, привязывать нужно именно через стандартный DOM-метод addEventListener(). Похоже, jQuery ещё не знает о таком событии.

    В принципе, на кодировании изображений только в Firefox 3.6 можно было и остановиться. Но моим главным инструментом является Safari, поэтому решил попытаться реализовать поддержку и это браузера.

    Safari (Webkit)

    Четвёртый Safari тоже поддерживает drag’n’drop, но получить содержимое файла в этом браузере оказалось сложнее (в то же время гораздо интереснее).

    Начнём с того, что Safari не поддерживает FileReader, то есть читать файлы просто нечем. В evt.dataTransfer.files (см. предыдущий пример) содержится список объектов класса File, у которого есть только 2 публичных свойства: fileName и fileSize. Мы можем получить только имя файла, но не полный путь к нему.

    Нужно найти способ, как получить полный путь к файлу, чтобы можно было хоть как-то загрузить его в браузер. Рассматриваем внимательно объект evt.dataTransfer, который является объектом класса Clipboard. У него есть метод getData(), позволяющий получить содержимое буффера обмена. Но этому методу нужно передать строку с названием типа данных, в котором хотим получить данные. Доступные типы определены в свойстве types. Простым перебором выясняем, что если передать тип text/uri-list, то получим список абсолютных путей ко всем файлам, разделённый переводами строк:

    function handleFiles(evt) {
    	// список перетаскиваемых файлов
    	var files = evt.dataTransfer.getData('text/uri-list');
    
    	console.log(files);
    	// выведет:
    	// file:///path/to/image1.png
    	// file:///path/to/image2.jpg
    }
    

    Итак, полдела сделано: мы получили список абсолютных путей к файлам, которые можем загрузить в браузер. Первая мысль, которая у меня возникла: создать <img> тэг, указав в качестве src путь к файлу, а после загрузки отрисовать его в canvas и получить data:url через метод toDataURL(). Однако эту мысль сразу же отбросил: во-первых, мы получим совершенно новое изображение, а не то, которое отдавали. Во-вторых, не понятно, что делать в JPEG-изображениями. В toDataURL() можно отдать тип, в котором хотим получить файл, но это будет то же самое, что сохранить JPEG как PNG, а потом обратно сохранить в JPEG, но уже с неизвестными параметрами сжатия.

    Второй способ, который пришёл мне в голову, это воспользоваться старым добрым XMLHttpRequest для загрузки файла. В принципе, идея неплохая, но есть одно жирное «но»: данные в responseText будут автоматически перекодированы браузером в текущую кодировку, что, естественно, нарушит целостность данных. В свежих версиях XMLHttpRequest (например, в IE8) есть свойство responseStream, в котором содержатся «чистые» байты файла, но Safari его не поддерживает.

    Выходом оказался хак, найденный где-то на MDC. Суть его заключается в том, что если у объекта класса XMLHttpRequest переопределить тип и кодировку файла с помощью метода overrideMimeType(), то в responseText окажутся правильные данные. В последних версиях jQuery у метода jQuery.ajax() в качестве параметра можно отдать метод xhr(), который должен вернуть XMLHttpRequest, с помощью которого будут загружаться данные. Вот как можно загрузить «чистые» данные:

    $.ajax({
    	url: file_path,
    	xhr: function(x) {
    		var xhr = new XMLHttpRequest();
    		xhr.overrideMimeType('text/plain; charset=x-user-defined');
    		return xhr;
    	},
    	success: function(data) {
    		console.log(base64_encode(data));
    	}
    });
    

    В метод success пришло правильное содержание файла, которое теперь нужно просто закодировать в base64 (соответствующая JS-реализация была найдена на просторах интернета).

    Копирование в буфер

    Файлы мы загрузили, перекодировали и вывели, теперь нужно придумать, как их удобно скопировать в буфер. Выводить здровенное <textarea>-поле и заставлять пользователя каждый раз выделять и копировать эти данные как-то совсем некошерно. Нужно сделать кнопочку, по нажатию на которую в буфер обена будут попадать нужные данные. В этом случае не нужно будет перегружать интерфейс ненужным данными, а также можно будет вывести несколько кнопок, которые будут копировать данные в разных форматах: обычный data:url, картинка и background-image.

    Единственный известный мне способ программно запихнуть данные в буфер обмена, это использование небольшой флэшки (флэшукапец, ага). Подробно об этом написано в блоге CSSing.org.ua, я же использовал слегка допиленную версию ZeroClipboard.

    Проблемы использования флэша на сайте уже много раз обсуждались, я же напишу о тех, которые возникли в разрабатываемом сервисе. Не знаю, как на винде, но на Маке одно только присутствие флэша на странице уже нагружает процессор, даже если эта флэшка ничего не делает. Причём, чем больше флэшек, тем больше нагрузка. Уже на 3-х загруженных файлах (у каждого 3 кнопки копирования; итого 3×3=9 флэшек) мой Core 2 Duo был загружен на 25%, при том что ни одного пикселя на странице не шевелилось. Ещё один побочный эффект — это влияние на анимацию. Когда пользователь удаляет блок с картинкой, содержимое блока тут же пропадало.

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

    Только я хотел нажать на кнопку «Опубликовать статью», как внутренне чувство заставило проверить всё ещё раз. Инстинкт меня не подвёл. На Маке я использую флэш-плагин версии 10,0,42,34, а на винде поставил самый свежий — версии 10.0.45.2. Несмотря на небольшую разницу в версиях в самой свежей сборке не работает копирование в буфер при локальном просмотре страницы. То есть пользователи Chrome, скачавшие страничку к себе на компьютер, попросту не смогли бы ничего скопировать. Похоже, Adobe решил окончательно закрутить гайки с буфером обмена.

    После часа безуспешного гугления был придуман хак, который позволяет копировать данные без использования флэша. Суть его заключается в том, что нужно создать на странице блок со свойством contentEditable="true", записать туда необходимую строчку через innerHTML, навести фокус (в этот момент браузер автоматически выделяет содержимое блока) и вызвать document.execCommand('copy'):

    <div id="copy-clip" contenteditable="true"></div>
    <script type="text/javascript">
    	function doCopy() {
    		var obj = document.getElementById('copy-clip');
    		obj.innerHTML = 'my new data';
    		obj.focus();
    		document.execCommand('copy')
    	}
    </script>
    

    По крайней мере при локальном запуске это работает, причём так, как надо.

    Анимация

    А теперь самое вкусное. Я давно присматривался к CSS трансформациям и анимациям, хотелось попробовать их на реальных проектах (подчёркиваю, речь идёт о качественной реализации реальных задач, а не о дурацких демках из разряда «смотрите, оно крутится!»). На данный момент CSS-трансформации поддерживают Safari (Webkit) и Firefox 3.6, CSS Transitions and Animations — только Webkit. Про Opera 10.5 молчу, ибо пользоваться этим абсолютно невозможно из-за чудовищных тормозов.

    Что я могу сказать про CSS-анимации в Safari: реализованы они довольно плохо. Есть довольно много неочевидных проблем. Для своего сервиса мне удалось их кое-как исправить, но не знаю, насколько эти проблемы могут быть решены в более крупных проектах.

    Вот что мне удалось узнать после работы с модными CSS-свойствами:

    1. Свойства вроде -moz-box-shadow очень сильно влияют на производительность. Уже на 7-ом блоке с файлом, у которого указано это свойство, начали появляться тормоза. Чем больше блоков — тем больше тормозит. Пользуйтесь CSS-декорациями вмеру.
    2. Одна из главных проблем при использовании CSS Transitions — это не совсем очевидный способ указания блоку начальных координат. Например, вы указали, что у блока должны плавно изменяться свойства left и top: -webkit-transition-property: left, top. Для того, чтобы переда началом анимации переместить блок в некие начальные координаты, плавные переходы нужно отключить. Сделать это можно обнулив либо -webkit-transition-property, либо -webkit-transition-duration:
      $(elem).css({
      	'-webkit-transition-duration': '0',
      	top: 10,
      	left: 20
      });
      

      А вот для того, чтобы включить плавный переход, нужно сначала вернуть отключённое transition-свойство, а уже потом, через setTimeout выставить нужные координаты:

      $(elem).css({
      	'-webkit-transition-duration': '0.5s'
      });
      
      setTimeout(function(){
      	$(elem).css({
      		top: 100,
      		left: 200
      	});
      }, 1);
      	
    3. В Webkit-браузерах для анимации перемещения объектов лучше использовать связку CSS Transition/Animation и translate(x, y) из CSS Transforms. Трансформации получают аппаратное ускорение (по крайней мере на Маке), а анимации включают субпиксельное сглаживание, что даёт полее плавное и естественное движение:
      subpixel

      Простое указание дробных пикселей (например, так: -webkit-transform: translate(5.5px, 1.6px);), к сожалению, подобного эффекта не дают.

    4. В следствие аппаратного ускорения CSS-преобразований, советую следить за размером блока. Если анимируете блок, ширина или высота которого больше 2000 пикселей (для айфона — 1024 пикселя), перед началом анимации блок «моргнёт». Судя по всему, это как-то связано с размером текстуры в OpenGL.
    5. После того, как такая анимация отработала, блок с файлом начало в прямом смысле слова «колбасить»:
      при наведении курсора на блок (после того, как отработала анимация появления) кнопки копирования соседних блоков начали прыгать куда-то вверх, а у надписей «поломалось» сглаживание:

      bug1

      Помогло, как ни странно, указание контейнеру с блоками position: relative;, а текстовым надписям — background: #fff; (здравствуй, старина IE).

    6. При наведении курсора на картинку она увеличивается/уменьшается с помощью CSS Animations (в Firefox — JS-анимация масштаба). Работает вроде неплохо, за исключением иногда «моргающей» тени и другого типа сглаживания у картинки. Но когда я указал z-index контейнеру с файлами, увидел вот такую картину:
      bug2

      Блоки произвольно исчезали и появлялись во время анимации. Помогло удаление z-index у контейнера. В моём случае это не критично, но подозреваю, в более крупных проектах с этим будут проблемы.

    Заключение

    Ещё года 2—3 назад задачи вроде перекодирования файлов прямо в окне браузера считались невыполнимыми. Но уже сегодня можно смело говорить, что браузеры могут не только страницы показывать, но и выполнять вполе утилитарные задачи. Теперь необязательно изучать фреймворки вроде Qt, чтобы написать кросс-платформенное GUI-приложение. Вполне достаточно накопленных в веб-разработке знаний, а современные JavaScript-движки способны быстро переваривать довольно большие объемы данных. Кто знает, может, скоро начнётся эра повального портирования существующих десктопных инструментов на JavaScript :) Лично я получил огромное удовольствие не только от результата, но и от процесса создания этого небольшого сервиса.

    UPD: Иван Михайлов сделал Cocoa-оболочку для этого сервиса, теперь его можно запускать как обычное Мак-приложение.

  • Равномерный фон под текстом

    Одно из модных направлений веб-дизайна последних лет — оформление заголовков контрастным фоном. Например, вот так:

    example

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

    padding

    Ближе всех к решению задачи когда-то подошёл akella, добавив border у родительского элемента. Но проблема не решена на 100%: в конце первой строки (место, где переносятся слова) всё равно нет отступа. Решения остальных ребят, которые присылались мне в твиттер, грешили одной и той же проблемой: нужно точно указать место разрыва строк.

    В простейшем случае, когда нужно добавить небольшой отступ, решение оказалось до боли простым. Есть одно «паразитное» CSS-свойство, от которого кодеры обычно избавляются — это свойство outline. Его особенность заключается в том, что во всех браузерах (по крайней мере в тех, в которых я проверял: Safari 4, Firefox 3.5, Opera 10, IE8) контур outline точно повторяет границы текстового элемента. Соответственно, эта строчка кода полностью решает нашу проблему:

    span.uniform-bg {
    	outline: red solid 0.3em;
    }
    

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

    firefox

    Первая проблема решается довольно просто: достаточно немного «втянуть» контур с помощью CSS-свойства outline-offset (либо -moz-outline-offset, эксклюзивно для Firefox), вторая — добавлением ещё одной обёртки с position:relative, чтобы поднять текст над контуром.

    Итоговое решение выглядит так:

    <style type="text/css">
    	.uniform-bg {
    		background:red;
    		position:relative;
    		outline: red solid 0.3em;
    		-moz-outline-offset:-0.04em;
    	}
    
    	.uniform-bg span {
    		position:relative;
    	}
    </style>
    <h2><span class="uniform-bg"><span>Hello everyone</span></span></h2>
    

    Оно не работает в IE6—7, в них не поддерживается свойство outline. Но, так как это исключительно декоративная задача, можно объединить её с решением от akella и получить почти идеальное решение.

    UPD: читатель Roman указал на баг в отрисовке фона в месте переноса строк в IE6—7. Немножко доработать напильником — и получится вполне приличное решение (обновил пример).

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

    Второй способ (upd)

    Тот же читатель Roman предложил ещё один способ решения задачи. Он основан на смещении трех слоёв относительно друг друга: например, если отступ равен x, то второй слой смещается на 2x вправо, а третий на –x, влево:

    method2

    Его можно немного упростить, убрав один слой и добавив левый border у контейнера. Способ более гибкий, чем с outline (который, как выяснилось, не очень дружит с Opera). На основе него я хотел сделать решение с фоновой картинкой, но столкнулся проблемой: вместе с переносом строк переносится и фон, то есть во второй строке фон начинается там же, где заканчивается в первой:

    bg-problem

    Метки: , , ,
  • CSS-свойство content: копировать или нет?

    Решил я для очередного своего проекта воспользоваться модным CSS-свойством content, чтобы немного облегчить страницу и сделать настройку внешнего вида более гибкой. Так как проект ориентирован на веб-разработчиков, об обратной совместимости со старыми браузерами (IE6—7) можно было не беспокоится. Но, к сожалению, меня ожидало большое разочарование от использования этого свойства. Нет, всё отображалось правильно, но конечному пользователю было бы неудобно пользоваться результатом.

    Что такое CSS-свойство content

    Кому ещё не удалось познакомиться с этим замечательным свойством, кратко расскажу о нём. Само название этого свойства говорит о том, что оно управляет неким содержимым. Согласно спецификации CSS2 это свойство применяется только к псевдо-элементам :before и :after, а с версии CSS3 станет доступно и для обычных элементов (небольшой реверанс в сторону Opera, которая это уже поддерживает).

    С помощью свойства content мы можем через CSS задавать текстовое содержимое для (псевдо-)элементов. Классический пример применения этого свойства — вывод содержимого ссылки рядом с элементом в версии сайта для печати:

    <style type="text/css">
    	a:after {
    		content: ' (' attr(href) ')';
    	}
    </style>
    <p>В нашем <a href="/catalog/">каталоге</a> вы найдёте много чего интересного.</p>
    

    С помощью псевдо-элемента :after мы задали некое содержимое после тэга <a>. Этим содержимым является результат конкатенации строк и функции attr(), которая выводит содержимое атрибута контекстного элемента. Браузер, полностью поддерживающий CSS2, изобразит этот код примерно так:

    content-example

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

    Проблема

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

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

    <style type="text/css">
    	.tag:before {
    		content:'<';
    	}
    
    	.tag:after {
    		content:'>';
    	}
    
    	.attr-value {
    		quotes:'"' '"';
    	}
    
    	.attr-value:before {
    		content:open-quote;
    	}
    
    	.attr-value:after {
    		content:close-quote;
    	}
    </style>
    <div class="tag">div <span class="attr-name">class</span>=<q class="attr-value">demo</q></div>
    

    Плюсы такого подхода: потребуется гораздо меньше элементов для раскраски тэгов (через псевдо-элементы :before и :after я могу задать произвольный цвет у угловых скобок). Для значений атрибутов я воспользовался тэгом <q> и CSS-свойством quotes, через которое определяются открывающие и закрывающие кавычки. Кому-то нравится использовать двойные кавычки в коде, кому-то — ординарные, при таком подходе их можно на лету поменять у всего документа. Как оказалось, выбор этого тэга и CSS-свойства стал важной частью эксперимента.

    В браузерах этот код выглядит замечательно:

    content-example2

    Но XML-документ должен не только красиво выглядеть, но и правильно работать: пользователь имеет право без проблем выделить и скопировать фрагмента документа, чтобы воспользоваться им, например, в своём любимом редакторе. И тут меня ожидало полное разочарование от использования свойства content. Я проверил результат копирования в своих браузерах — Safari 4, Opera 10, Firefox 3.5, IE8 — и получил вот такой результат:

    • Safari: div class=demo
    • Opera: <div class="demo">
    • Firefox: div class="demo"
    • IE8: <div class="demo">

    Как видите, все скопировали текст по-разному: Safari не скопировал content-данные в принципе, Opera и IE8 скопировали всё, а Firefox скопировал только кавычки вокруг атрибута.

    Затем я решил вместо вместо элемента <q> написать обычный <span>, и получил вот такой результат:

    • Safari: div class=demo
    • Opera: <div class="demo">
    • Firefox: div class=demo
    • IE8: <div class="demo">

    Всё то же самое, но Firefox уже не скопировал кавычки.

    Выводы

    Из этого небольшого эксперимента я сделал для себя следующие выводы:

    • Safari в принципе не понимает CSS-свойство quotes. То, что браузер отобразил кавычки вокруг <q> элемента — исключительно стандартная реакция на него. Кавычки нельзя будет поменять через свойство quotes, например, на ординарные — они так и останутся двойными. А если элемент переименовать в <span>, то и вовсе пропадут.
    • Firefox при копировании текста обращает внимание на название элемента: если это <q> — кавычки скопируются, для другого элемента получите пустоту.
    • Firefox всегда копирует двойные кавычки для тэга <q>, даже если вы измените их на что-нибудь другое (на «ёлочки», например). То есть сделать трюк с управлением копирования символов у вас не получится. Либо двойные кавычки, либо ничего.
    • IE8 при копировании обращает внимание на тип элемента: например, если прописать тэгу display: list-item, то скопируется буллит (хотя на странице он не будет отображаться).

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

  • Ищу помощника

    Мне в компанию очень нужен помощник или помощница.

    UPD: ваканся закрыта, но скоро мне ещё понадобятся сотрудники. Если интересно — пишите.

    Исходные данные

    Есть проект Аймобилко, где я являюсь техдиректором и лицом, всячески заинтересованным в повышении количества продаж и качества предоставляемых услуг. Сайт написан на Java (этим занимается отдельный человек), использует связку XML/XSL для генерации результата. На сайте много JS-скриптов (исходники весят около 1,5 МБ, без учёта подпроектов).

    Моя основная цель — сделать удобный проект для продажи цифрового контента. Именно поэтому там нет мудацкой регистрации с капчей или обязательным подтверждением по электронной почте, а любую покупку можно совершить буквально в два клика без регистрации. Это как бы намекает, что мы не перекладываем программерские проблемы (вроде большого количества «левых» регистраций) на пользователя, а сами их успешно решаем, но на это требуется больше времени и сил.

    В работе используются инструменты по следующим ключевым словам: Eclipse, Ant, XSL, XML, HTML, CSS, JavaScript, Python, SVN, Redmine, Mylyn.

    Что требуется

    Нужен человек на полный рабочий день, который будет верстать новые и дорабатывать старые макеты, делать из них XSL-шаблоны и прикручивать к сайту. Знание XSL очень желательно, но не обязательно; если надо — научу. Это минимум.

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

    Что делать

    Если вам интересна эта вакансия, напишите мне на serge.che@gmail.com письмо с кратким рассказом о себе, а также 3—4 ссылки на свои самые интересные работы. Хочу сразу предупредить, что:

    • меня тянет блевать от словосочетаний вроде «валидная семантичная вёрстка», «пора переходить на html5» и прочих задротских умопомешательств;
    • за слова «это сделать невозможно» буду сразу бить по башке;
    • я до сих пор поддерживаю IE6 на необходимом минимуме: главное, чтобы всё работало и выглядело прилично, но можно без тенюшек и скруглённых уголков;
    • нужен человек, который будет участвовать в жизни проекта, а не делать работу за зарплату (которая по результатам собеседования).

    Офис находится в районе м. Павелецкая.

    Метки:
  • Вёрстка растягивающихся сайтов

    В этой статье я поделюсь способом вёрстки растягивающихся сайтов (а других, как оказалось, я верстать не умею), которым пользуюсь последние 2—3 года. Этот способ применяется для сложных модульных сеток; он лёгок в применении, но сложен в понимании и у него есть ряд недостатков. В целом, представленная здесь информация пригодится и веб-дизайнерам, так как сам макет сайта должен быть правильно подготовлен.

    Начнём с простого. Предположим, у нас есть вот такой макет растягивающегося сайт:

    01

    На первый взгляд всё довольно просто: типовая трёхколоночная сетка (ширина колонки — 25%), одна колонка — меню, две колонки — контент, и всё это располагается по центру. Типовая вёрсткой такого макета может быть следующей: заключаем оба блока в контейнер шириной 75%; меню в этом случае будет шириной 33%, контент — 67%. Саму обёртку выравниваем по центру с помощью margin: 0 auto, либо просто смещаем влево. Первый способ предпочтительнее, так как ведёт себя адекватно, если мы ограничим минимальную ширину обёртки. Визуализация этого решения:

    02

    Проблема

    Казалось бы, ничего сверхъестественного, задача решена. Но вот дизайнер вдруг захотел красиво оформить информацию в одном из разделов сайта, нарисовав выносной блок за пределами контента:

    03

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

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

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

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

    Ширина контента — 67%, меню — 33%. Чтобы блок встал ровно, его нужно сместить на 49.25% (33 / 67 * 100 ≈ 49.25). Во-первых, наш результат получился приблизительным, во-вторых, все браузеры (кроме Firefox 3) довольно своеобразно работают с дробными процентами (да и с процентами вообще), а некоторые вообще их не воспринимают. В итоге получается, что у нас нет кросс-браузерного способа совместить эти блоки при выбранной разметке.

    Поиск решения

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

    01

    Внимательный читатель обратит внимание на то, что ширина меню ровно в 2 раза меньше ширины контента (50 / 25 = 2). Деление получается целочисленным (нет дробей), а значит мы можем создать кросс-браузерное и — самое главное — точное решение проблемы.

    Поступим следующим образом. Завернём оба блока в контейнер, ширина которого будет не 75%, как раньше, а 50% (то есть равна ширине контента). Сам контент будет шириной 100%, а меню — 50%, при этом смещено влево на свою ширину.

    04

    Приблизительный код этого примера:

    <style type="text/css">
    	#page {
    		position:relative;
    		margin:0 auto;
    		width:50%;
    		left:10%;
    	}
    
    	#menu {
    		width:50%;
    		margin-right:-50%; /* чтобы правильно в IE работало */
    		position:relative;
    		left:-50%;
    		float:left;
    	}
    
    	#content {
    		width:100%;
    		float:left; /* Новый контекст форматирования */
    	}
    </style>
    <div id="page">
    	<div id="menu"></div>
    	<div id="content"></div>
    </div>
    

    С помощью такой разметки мы можем легко решить нашу задачу с выносным блоком: делаем его шириной 50% и на эту же величину смещаем влево. Более того, с помощью такой разметки можно сделать более интересную вёрстку с выравниванием по основным трём колонкам:

    05

    Этот очень простой пример должен обратить внимание два ключевых момента такого способа вёрстки: выбор размера базовой колонки и выбор размера контейнера (точка отсчёта). Рассмотрим эти параметры чуть подробнее.

    Усложняем задачу

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

    06

    Проблема в том, что 100 не делится на 6 без остатка (100 / 6 ≈ 16.66666), а дизайнер по-прежнему хочет выравнивать контентные блоки по границам основных колонок.

    Одним из решений этой проблемы может быть следующее: сделаем размер контейнера равным ширине двух колонок. Размер внутреннего блока в этом случае будет равен 50%, что соответствует размеру основной колонки. А указав этому блоку margin-right:-50% мы уберём его влияние на поток по горизонтали: это позволит нам создать сколько угодно блоков в контейнере, каждый из которых будет влиять на его высоту, но не на ширину.

    07

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

    Проблема с расчётом процентных значений

    Если в предыдущем примере поиграться с размером окна браузера, то можно заметить, что во всех браузерах, кроме Firefox 3, появляются однопиксельные зазоры между некоторыми блоками:

    screenshot

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

    Проценты — это относительная величина, которая пересчитывается в абсолютную — пиксели (ну хорошо, пиксели — это тоже относительная величина, которая зависит, например, от DPI экрана). То есть когда браузер видит, например, процентную ширину у блока, он должен рассчитать значение в пикселях относительно контейнера этого блока. Предположим, ширина контейнера равна 60 пикселям, а внутреннего блока — 50%. Ширина в пикселях этого блока будет равна: 60 × 0.5 = 30px. Значения красиво умножились/поделились. Но что будет, если ширина контейнера равна 61px? 61 × 0.5 = 30.5px — браузер не может отрисовать половину пикселя, поэтому он округляет это значение в меньшую или большую сторону.

    На самом деле алгоритм гораздо сложнее: например, 4 блока подряд шириной 25% в современном браузере должны занимать 100% ширины контейнера; какие-то блоки будут меньше, какие-то больше. Мы же рассматриваем самый простой случай.

    Итак, ширина блока получилась 30.5px, браузер для себя округляет её до 30px. Что будет, если в этот блок мы вложим ещё один, шириной 200%? По идее его ширина должна быть равна ширине контейнера, то есть 61px. Но так не получится, потому что абсолютная ширина промежуточного блока равна 30px, соответственно: 30 × 2 = 60px. Получили расхождение в 1 пиксель. Из всех современных браузеров правильное значение даст только Firefox 3: судя по всему, он где-то внутри хранит истинное значение ширины, от которого делает все расчёты.

    Но! Обратите внимание, что абсолютная ширина нашего нового внутреннего блока всегда будет чётной. Например, если ширина промежуточного блока будет рассчитана как 31px, то внутренний блок будет шириной 31 × 2 = 62px. А чётные числа, как известно, делятся на 2 без остатка.

    Соответственно, решением нашей проблемы с зазорами в шестиколоночном макете будет создание ещё одной обёртки, шириной в одну колонку, а внутренней обёртке задать ширину в 200%, чтобы получилась чётная абсолютная ширина у контейнера. Убеждаемся, что всё работает правильно.

    Выводы

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

    1. Определяем ширину колонки модульной сетки. Тут, конечно, многое зависит от дизайнера: если он будет лепить блоки как попало, то никакие стандартные способы не подойдут. Мне очень повезло, что в САЛ практически у всех дизайнеров есть голова на плечах. Перед тем, как что-то нарисовать, они разбивали макет на несколько колонок одинаковой ширины, по которым выравнивали блоки. Если же макет не укладывался в мою схему, я немного раздвигал блоки, выравнивая их по моим колонкам и показывал дизайнеру — он был не против. Важно понимать, что ширина вашей колонки не всегда будет равна ширине дизайнерской колонки. Это можно увидеть в самом первом примере, где ширина свёрстанной колонки равна двум дизайнерским. Обычно, когда я получаю макет от дизайнера, я использую его гайды исключительно для того, чтобы увидеть принципы выравнивания блоков, после чего я создаю свою разбивку на колонки.
    2. Определяем ширину основного контейнера. Этот контейнер я называю точкой отсчёта (хоть это и не точка вовсе). Важно, чтобы ширина точки отсчёта позволяла создавать ширину колонки, которая делит 100 без остатка: 100%, 50%, 20%, 10%, 5%. Создав колонки такого размера, можно точно позиционировать и раздвигать выносные блоки внутри контента.
    3. Добавляем ещё обёртку для точного округления процентов. Это если вам необходимо точное выравнивание по блокам с видимыми границами. В примере я показал, как создать блок, ширина которого всегда кратна 2. Точно так же можно создавать обёртки, ширина которых кратна, например, 4 (25%/400%).

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

    1. Фотогалерея Imperia Private Banking. Блок с галереей растягивается точно (±1 пискель) по размерам общего контейнера, при этом сам контентный блок занимает половину ширины и располагается по центру контейнера. Галерей на странице может быть сколько угодно (как и контента между ними), при этом они будут находится в нормальном потоке документа. На этом же сайте можно увидеть ещё несколько примеров того, как контентные выносные блоки выравниваются по колонкам макета.
    2. Банк AB.LV. Сайт довольно большой, содержит много разного контента и едва заметных декораций (однопиксельная тень вокруг основного блока, например). На странице «О банке» можно увидеть, как четвёртая колонка в контенте выравнивается точно по основному меню (это чистой воды дрочерство, но дизайнер был доволен, да и мне было не сложно такое сделать).
    3. (примеров, на самом деле, много, но не могу вспомнить самые выразительные).

    Недостатки

    Куда же без них. Самый главный — способ совершенно не подходит для макетов, которые должны растягиваться на всю ширину окна браузера. Из-за тех самых округлений процентных значений есть большой риск того, что какой-нибудь блок выйдет на 1px за пределы окна, создав тем самым горизонтальный скролл. Ещё кому-то может может показаться недостатком то, что размеры блоков меняются с шагом, больше одного пикселя. Ну и не забываем, что дизайнер тоже должен включить мозг перед тем, как что-то нарисовать. Хотя, конечно, если постараться, то можно сверстать и совсем экзотические варианты, выбрав размер колонки по-меньше (например, 10%).

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

    Метки: , ,
  • Zen Coding для textarea

    Представляю первую бета-версию плагина, который позволяет использовать мощь Zen Coding у себя на сайте без всяких плясок с бубном: Zen Coding for <textarea>. Название говорит само за себя: ZC работает прямо в <textarea>. Для работы достаточно подключить всего один JS-файл к себе на сайт.

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

    Плагин использует технику под названием event delegation: вешаются события по отлову нажатий клавиш на родительский документ; когда пользователь пытается вызвать какую-нибудь команду (например, Expand Abbreviation), плагин проверяет, какой элемент является источником. Если это <textarea> — отрабатываем команду, если нет — просто пропускаем событие. Таким образом, никакой дополнительной настройки для работы плагина не требуется: подключаем файл и радуемся жизни.

    Испытать плагин можно прямо на это странице в форме добавления комментария. Чтобы узнать допустимые сочетания клавиш достаточно кликнуть на иконке «Powered by Zen Coding» рядом с полем ввода.

    Плюшки

    Помимо основных возможностей Zen Coding плагин позволяет сделать написание кода в <textarea> гораздо более приятным занятием. Во-первых, можно задействовать клавишу Tab для разворачивания аббревиатур. Если аббревиатуру не получается развернуть, то добавляется символ табуляции (то есть просто делается отступ, как в обычных редакторах). Во-вторых, можно включить форматирование кода при добавлении переводов строк (нажатие на Enter). Новая строка будет добавлена вместе с отступом предыдущей строки, а если каретка находилась как раз между открывающим и закрывающим тэгом — будет добавлено дополнительное форматирование.

    По умолчанию эти опции отключены, их можно включить одним из доступных способов.

    Настройка

    У плагина есть ряд базовых настроек, которые можно в любой момент перекрыть. Все эти настройки записаны в переменной default_options файла manager.js:

    • profile — профиль форматирования результата разворачивания аббревиатур. По умолчанию применяется 'xhtml', доступны также 'plain', 'html', 'xml'.
    • syntax — синтаксис языка, с которым работаем в поле. По умолчанию это 'html', доступно также 'css', 'xml', 'xsl'. Можно создавать свой синтаксис (см. zen_settings.js).
    • use_tab – использовать клавишу Tab для разворачивания аббревиатур/добавления отступов.
    • pretty_break — включить форматирование переноса строк.

    Изменить настройки можно как глобально (применяются ко всем полям ввода), так и локально (применяются к конкретному полю).

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

    	zen_textarea.setup({
    		use_tab: true,
    		pretty_break: true
    	});
    

    Для того, чтобы указать локальные настройки для конкретного поля достаточно указать ему класс вида zc-{название параметра}-{значение}. Например, для того, чтобы указать, что в данном поле нужно использовать синтаксис XSL, а также включить форматирование переносов строк, пишем вот такие классы:

    	<textarea class="zc-syntax-xsl zc-pretty_break-true"></textarea>
    

    Также можно переназначить сочетания клавиш на более привычные, для этого есть методы zen_textarea.shortcut(keystroke, action_name) и zen_textarea.unbindShortcut(keystroke). В качестве аргумента keystroke отдаем текстовое описание сочетания клавиш, например Shift+Alt+D, в качестве аргумента action_name — название действия, которое нужно выполнить.

    Для создания шорткатов можно использовать клавишу Meta: на Маке это будет означать Command, на PC — Ctrl. Полный список доступных действий и их шорткаты:

    addShortcut('Meta+E', 'Expand Abbreviation');
    addShortcut('Tab', 'Expand Abbreviation');
    addShortcut('Meta+D', 'Balance Tag Outward');
    addShortcut('Shift+Meta+D', 'Balance Tag inward');
    addShortcut('Shift+Meta+A', 'Wrap with Abbreviation');
    addShortcut('Ctrl+Alt+RIGHT', 'Next Edit Point');
    addShortcut('Ctrl+Alt+LEFT', 'Previous Edit Point');
    addShortcut('Meta+L', 'Select Line');
    addShortcut('Enter', 'Format Line Break');
    
    Метки: , , , ,
  • Zen Coding v0.5

    Как, наверно, многие догадались по постам на Smashing Magazine, Ajaxian и Хабре, вышел Zen Coding v0.5. Видео, описывающие прелести нового ядра:

    Все видимые нововведения описаны на смашинге, посмотрим, что изменилось «под капотом»:

    • Новый формат описания аббревиатур. Никаких объектов, используются «человеческие» описания тэгов: 'img': '<img src="" alt=""/>'. Во время первого запуска парсер читает настройки и преобразовывает их в специальные объекты для быстрой работы. В данном случае важен синтаксис тэга: например, /> в конце определения означает, что тэг одиночный и не может содержать потомков.
    • Переменные. В настройках добавилась специальная секция variables, в которой определяются переменные, подставляемые в аббревиатуры. Переменные подставляются как ${variable}, но есть ряд предопределённых элементов, которые имеют особые значения: ${id}, ${class}, ${child}. Переменные нужны для того, чтобы можно было быстро менять некоторые стандарнтные значения в аббревиатурах и сниппетах (например, язык). В дальнейшем планируется задавать свои переменные для отдельных проектов.
    • Профили вывода. Можно настроить формат вывода генерируемого кода: выводить в HTML/XHTML диалекте, менять регистр тэгов и атрибутов, менять типы кавычек. Первые наброски документации: http://code.google.com/p/zen-coding/wiki/ZenCodingAPI
    • Сниппеты поддерживают атрибуты id и class. Это можно увидеть на видео в самом конце, в примере с Django блоком. В сниппете можно указать, куда должно подставляться значение атрибутов id и class — получаем, таким образом, легко расширяемые сниппеты.
    • Наследование. Аббревиатуры и сниппеты для конкретного языка могут наследоваться от других языков. Например, для XSL я указал, что его снипетты должны наследоваться от HTML — таким образом при редактировании XSL можно пользоваться стандартными HTML-аббревиатурами + добавлять специфичные для конкретного языка. Наследование задается через параметр extends, указывая через запятую языки:
      'xsl': {
      	'extends': 'css,html',
      	'abbreviations': {
      		...
      	}
      }
      
    • Улучшен API самой библиотеки. Из JS-версии удалил все зависимости от Eclipse, теперь код работает в любом стандартном JS окружении. Добавилось несколько вспомогательных функций для упрощения работы. Но API всё ещё очень далёк от идеала, буду его улучшать.
    • Все комментарии в коде переведены на английский язык.

    Буквально сегодня утром сделал объединил свою ветку разработки с транком, так что там теперь лежит последняя версия. Больше информации о Zen Coding (ну и на меня — красивого — посмотреть :)) можно увидеть в моём докладе на 404fest.

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

    Notepad++

    Все очень хотят поддержку этого редактора, но проблема в том, что у него нет возможности добавить расширения через скрипты. Единственный известный мне способ расширить NP++ — написать плагин на C++, используя API редактора. На сях я не пишу, приложения под винду никогда не создавал, поэтому нужна помощь человека, который в этом разбирается. В идеале: нужно написать мост WSH-C++, который позволит писать расширения на JavaScript для NP++. Как минимум: предоставить простой API на JavaScript специально для Zen Coding, который я буду дёргать и говорить, что нужно сделать (опять же, с помощью WSH).

    В TextMate не всё работает

    Да, в TextMate пока работает только разворачивание аббревиатур. Обёртывание аббревиатурами и выделение тэгов не работают — опять же, из-за ограничений API редактора. Но есть уже некоторые наброски решений этой проблемы (спасибо Антону Полещуку).

    Метки: , ,
  • Универсальный способ декорирования блоков

    В прошлой домашке я предложил читателям придумать способ вёрстки блоков со скругленными уголками и тенью. Если посмотреть на решения, то увидите, что большинство из них очень похожи друг на друга: 4 элемента, разбросанных по углам, одинаково «необычный» вид картинки, небольшие различия в наложении блоков. Давайте рассмотрим подробнее, за счет чего работают эти способы, а также почему эта статья не называется «Создание скруглённых блоков с тенью».

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

    1

    Внутри блока есть контент неопределенной ширины и высоты, тень полупрозрачная; сам блок может иметь как заданную ширину (пиксели, проценты), так и автоматическую (width: auto). Наша задача: найти наиболее оптимальный способ вёрстки подобных блоков. Под оптимальностью я подразумеваю наименьшее количество элементов, наименьшее количество графических файлов, работа во всех современных браузерах, минимальное количество правок под конкретный браузер. Все эти принципы так или иначе влияют на производительность и надёжность нашего решения, особенно на крупных проектах.

    Справедливости ради стоит отметить, что мы будем рассматривать неопределенность габаритов контента в каком-то определенном диапазоне, например, 1000×1000 пикселей. То есть я буду рассказывать про какие-то небольшие контекстные всплывающие блоки, которыми сейчас переполнены различные сайты. Если вам нужно будет, например, сделать тень у блока, в котором содержится основной контент сайта, то лучше выбрать другой способ.

    Простой способ

    Если присмотреться внимательно на пример выше, то можно сразу же найти простое и оптимальное решение: мы разделим наши декорации на 4 зоны, в каждой из которых покажем определенный фрагмент одной фоновой картинки:

    2

    • Первая область: растягивается по горизонтали и вертикали, background-position: top left;
    • Вторая область: ширина фиксированная, растягивается по вертикали, background-position: top right;
    • Третья область: растягивается по горизонтали, высота фиксированная, background-position: bottom left;
    • Четвертая область: ширина и высота фиксированная, background-position: bottom right.

    Реализовать такую конструкцию — проще простого, но есть один нюанс: блоки должны растягиваться не на всю ширину контейнера, а на ширину контейнера минус ширина бокового блока (в данном случае это 2 и 4). То же самое касается высоты. Решается эта задача довольно просто. Не каждый знает, что задавать размеры блокам можно не только с помощью CSS-свойств width и height , но и с помощью комбинаций left/right и top/bottom у абсолютно спозиционированных элементов. Примерный код может выглядеть так:

    <style type="text/css">
    	.shadowed {
    		position: relative;
    		left: 200px;
    		top:  100px;
    		padding: 10px;
    		width: 30%;
    		max-width: 450px;
    	}
    
    	.sh {
    		position: absolute;
    		background: url(./shadow.png) no-repeat;
    		z-index: -1;
    	}
    
    	.tl {
    		/* задаем высоту */
    		top: -6px;
    		bottom: 12px;
    
    		/* задаем ширину */
    		left: -11px;
    		right: 14px;
    	}
    
    	.tr {
    		width: 25px;
    		top: -6px;
    		bottom: 12px;
    		right: -11px;
    		background-position: top right;
    	}
    
    	.bl {
    		left: -11px;
    		right: 14px;
    		bottom: -16px;
    		height: 28px;
    		background-position: bottom left;
    	}
    
    	.br {
    		width: 25px;
    		height: 28px;
    		right: -11px;
    		bottom: -16px;
    		background-position: bottom right;
    	}
    </style>
    <div class="shadowed">
    	Hello world
    	<div class="sh tl"></div>
    	<div class="sh tr"></div>
    	<div class="sh bl"></div>
    	<div class="sh br"></div>
    </div>
    

    Если вы откроете пример в любом современном браузере, то увидите, что всё работает замечательно. Но ребята из Редмонда не могли пройти мимо такой халявы и решили усложнить нам жизнь своим продуктом под названием Internet Explorer 6, в котором:

    • не работает растягивание с помощью top/bottom и left/right;
    • свойства bottom и right работают не правильно (позиция элемента отсчитывается от чётной ширины/высоты контейнера);
    • полупрозрачный PNG нельзя наложить и позиционировать как обычный фон.

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

    Растягивание по горизонтали

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

    3

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

    4

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

    5

    Решить эту проблему, опять же, довольно просто: обрамим первый и второй блок еще одним блоком, которому выставим width:100%; overflow: hidden и верхний и боковые паддинги по размеру тени. Так как мы задали ширину, то боковые паддинги увеличат размер блока до нужных значений и наша тень будет полностью отображаться. А overflow: hidden с основного контейнера можно убрать, и это даст нам дополнительное преимущество: мы сможем разместить внутренний элемент за границами контейнера (например, кнопку закрытия).

    Добавив padding у внутреннего контейнера, мы столкнёмся с тем, что первый блок будет меньшего размера, чем нам нужно. Но, опять же, так как у него задана ширина, мы можем «добить» ширину до нужного значения с помощью свойства padding-right:

    4_2

    Картинка

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

    sprite-sample

    Правая декорация у первого блока будет скрыта overflow:hidden контейнера, а ширина второго блока равна ширине правой декорации и покажет только её. А если перенести вверх еще и нижнюю часть, то мы сможем наложить один и тот же спрайт на все 4 блока:

    sprite2

    Конечно же, первый и второй блок нужно будет сместить вверх на высоту нижней декорации.

    Расположение блоков справа и снизу

    Как я уже отметил, в IE6 неправильно работают CSS-свойства right и bottom, и для нас это проблема, так как мы имеем дело с полупрозрачными элементами. Любая нестыковка блоков даже в 1 пиксель будет сразу бросаться в глаза.

    Свойство right исправить очень просто: достаточно вместо него воспользоваться margin-left:100% — это разместит блок ровно у правого края, а с помощью left можно подтянуть блок в нужное место. С bottom немного сложнее: я не знаю альтернативных путей, кроме как позволить самому контенту опустить этот блок до нужного уровня. На предыдущем шаге мы добавили обёртку с двумя блоками внутри, туда же мы добавим и контент. Под обёрткой разместим наши нижние блоки.

    Эта обёртка и будет определять, на какой высоте окажутся блоки 3 и 4. Согласно спецификации CSS, элемент с position: absolute, у которого не указаны позиционирующие свойства — top/right/bottom/left — должен размещаться в том месте потока документа, где размещался бы статический элемент. Это очень удобно, так как благодаря этому можно делать различные трюки в виде выносных блоков, привязанных к определённому слову в тексте (например, смотрите выноску про Hyatt Hotel на сайте Башни Федерации).

    У этой обёртки задан overflow: hidden, который выполняет 2 функции: скрывает ненужные куски внутренних декоративных блоков и задает контекст форматирования. Это значит, что никакие марджины внутри не будут выпирать наружу, что гарантирует нам точную позицию нижних блоков.

    Нижние блоки

    Если помните, мы убрали overflow: hidden у самого контейнера. Поэтому, чтобы растянуть блоки 3, 4 так же, как и 1, 2, нам, похоже, придется добавить еще одну обёртку. Однако есть одно CSS-свойство, о котором кодеры часто забывают — это свойство clip. С помощью него мы и скроем выпирающий левый край.

    Результат

    Надеюсь, вы поняли саму идею, за счет чего работает большинство решений, присланных пользователями. Кратко подведу итог: для верстки декорированных блоков понадобится 5 элементов и одна картинка. Элементы располагаются следующим образом: одна обёртка, в которой находятся левый верхний и правый верхний углы, а также контент. У этой обёртки выставлен overflow: hidden, который скрывает выпирающие части у декоративных блоков, а также задает контекст форматирования. Эта же обёртка определяет позицию двух нижних блоков по вертикали. Выпирающая левая часть у левого нижнего блока отрезана с помощью clip. Спрайт мы подогнали таким образом, чтобы нам не нужно было указывать background-position, который всё равно не сработает в IE6, так как там мы воспользуемся фильтрами. В этом спрайте мы как бы вывернули блок наизнанку, переместив нижнюю часть вверх, а правую — влево.

    А вот и моё решение. Как видно из примера, решение полностью кроссбраузерное, для IE6 понадобилось всего лишь добавить padding у некоторых блоков (это можно сделать и с помощью одноразового expression).

    С помощью этого способа можно декорировать любой блок, где надо равномерно покрыть все 4 стороны. Например, можно плоскую и скучную обложку книги превратить в объёмную, как это сделано на сайте Аймобилко (правда, там используется немного другой способ из-за технических особенностей сайта):

    imobilco

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

    Метки: , , ,

← старое