There is one particular day in my life that went into reading everything I could find about applying SVG filters on HTML content in Webkit/Blink and pulling my hair why didn’t my code work. See, I had an element with a SVG filter applied as a URI reference and the filter didn’t appear in Chrome and Opera. I tryed embedding the filter definition into the HTML – didn’t work, I tryed recreating the filter with the filter functions available in CSS – could’t create the same effect, but filters did work. Thet I noticed that the filters shows up while the JavaScript is loading, and after disabling JS throu DevTools the filter was there. And after toggling every single piece of JavaScript on the website on and off I managet to pinpoint the cause of my trobbles – a function that applied a class to the body that triggered an animation on a element that is siblink to the one with the SVG filter applied. Then I remembered reading about Chrome not using the GPU for SVG filters applied with URI, but using it for the shortcut functions in CSS. And then I knew – when applying the animation, Chrome rendered the whole container with the GPU and the SVG filter disappeard. And I did try to use 2d functions for the animation, but Chrome still used the GPU and broke the filter. So, if you ever try to use complex SVG filters together with CSS animation, be prepared for trouble!
I know what you did onbeforeunload
от ГонзоThere are a couple of questions on StackOverflow about distinguishing download links in onbeforeunload event handler, the usual use case being skipping loading animation. The simple solution is to use the download attribute on the link itself, but this can’t be applied for forms. I had the same problem and fortunately I found a solution.
What I did was the obvious thing of checking the properties of the event object, passed to the handler. In Firefox there is explicitOriginalTarget property and when the event is triggered by a form submission, the property is a reference to the submit button (if the form is submitted by pressing the button). In Chrome there is no such property, but there is another one that does the job – srcDocument.activeElement. This also points to the submit button of the form. Internet Explorer on the other hand does not have any of these shortcuts, so I had to use the long reference event.currentTarget.document.activeElement.
So what I did was add a data-download attribute to the form and check for it in the onbeforeunload handler like this:
window.onbeforeunload = function (e) {
var target = e.currentTarget.document.activeElement;
if ( target.form ) {
target = target.form;
}
if ( ('getAttribute' in target) &&
(target.getAttribute('download') != undefined ||
target.getAttribute('data-download') != undefined) ) {
return;
}
// Show loading spinner or do whatever you need to.
};
The above code does two things – polyfill browsers that don’t support the download attribute and apply similar logic to forms. It works in IE 9, 10, 11 and Edge, latest Firefox and Chrome.
Responsive header images with WordPress
от ГонзоГолемите картинки, заемащи почти целия екран от доста време са на мода, но освен да впечатляват потребителя, те могат и доста да го изнервят докато чака да се заредят. Проблемът става съвсем явен когато потребителя разглежда сайта на екрана на телефона си, особено ако на мястото на което се намира няма 3G покритие. За решаването на този проблем на помощ идват отзивчивите картинки.
Годината е вече 2016та, най-популярните браузъри от доста време поддържат srcset, sizes и picture, така че няма причина да не ги използваме. А с новата версия 4.4 на WordPres това е още по-лесно. Не че с предишните беше трудно, просто трябваше да се инсталира разширението RIGC Responsive Images.
И така, постановката е проста, в горната част на сайта, под главата или като част от нея, искаме да поставим голяма картинка, която да заема цялата ширина на екрана. Освен това сайтът ще е с отзивчив дизайн, все пак е 2016 година вече. До тук нищо сложно, но като погледнем картинката с пропорции 16:9 на екрана на телефона в портретен режим и виждаме, че нещо е е така. Тогава сигурно бихме искали картинката също да е в портретен режим или поне да отива към квадрат, може би да увеличим основния елемент в нея. За да решат този проблем, хората от Responsive Images Comunity Group измислиха елемента picture.
Веднага ви давам пример:
<picture> <source media="(min-width: 45em)" srcset="large.jpg"> <source media="(min-width: 32em)" srcset="med.jpg"> <img src="small.jpg" alt=""> </picture>
Браузърите, които поддържат picture, ще заредят първия елемент source, в чийто атрибут media е посочена медийна заявка, отговаряща на устройството на потребителя. Браузърите, които не поддържат picture просто ще покажат елемента img.
За да направим заглавната картинка в WordPress да използва елемента picture първо трябва да накараме WordPres да създава варианти на картинката с необходимите ни размери:
function image_sizes() {
add_image_size( 'image-big', 1920, 1080, true );
add_image_size( 'image-medium', 1024, 768, true );
add_image_size( 'image-small', 480, 480, true );
}
add_action( 'after_setup_theme', 'image_sizes' );
След това идва интересната част. Тук предполагам, че темата вече поддържа custom-header. В предишните версии на WordPress заглавната картинка се показва обикновено с функцията header_image(). Но в най-добрия случай с тази функция ще получите img елемент с атрибути srcset и sizes, което не е това, което искаме. За да можем да използваме дефинираните от нас размери на картинки първо трябва да вземем ID на картинката и след това да използваме wp_get_attachment_image_src() за искания размер. Ако търсите начин да вземете ID на заглавната картинка в codex-а, няма да намерите (поне аз не успях), но един преглед на кода на WordPress веднага ще ви посочи get_custom_header() като решение на проблема. Накрая получаваме това:
<?php $header = get_custom_header(); ?> <picture> <?php $src = wp_get_attachment_image_src()( $header->ID, 'image-big' )[0]; ?> <source media="(min-width: 1024px)" src="<?php echo esc_attr($srcset); ?> /> <?php $src = wp_get_attachment_image_src()( $header->ID, 'image-medium' )[0]; ?> <source media="(min-width: 480px)" src="<?php echo esc_attr($srcset); ?> /> <?php $src = wp_get_attachment_image_src()( $header->ID, 'image-small' )[0]; ?> <img src="<?php echo esc_attr($src); ?>" /> </picture>
Това е добре, но има един недостатък – една и съща картинка се сервира при доста голям диапазон от размери на екрана и съответно в доста случаи ще натовари клиента с излишен трафик и браузъра с по-тежко преоразмеряване на голяма картинка. Решението е на всеки source елемент вместо една картинка със src да подадем набор от размери чрез srcset. Тук на помощ идва функцията wp_get_attachment_image_srcset, която е нова в WordPress 4.4, в по-ранни версии може да се използва чрез разширението RICG Responsive Images. Тя връща srcset атрибут със всички дефинирани размери картинки със същата пропорция като подадения като втори параметър размер.
<?php $header = get_custom_header(); ?> <picture> <?php $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'header-image-small' ); $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : ''; ?> <source media="(min-width: 1024px)" <?php echo $srcset; ?> /> <?php $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'wide-big' ); $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : ''; ?> <source media="(min-width: 600px)" <?php echo $srcset; ?> /> <?php $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'square-medium' ); $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : ''; ?> <source <?php echo $srcset; ?> /> <img src="<?php echo esc_attr(wp_get_attachment_image_src($attachment_id, 'header-image-base', false)[0]); ?>" /> </picture>
И така получаваме картинка в главата, която наистина реагира на размера на екрана, с още малко усилия може да подавате различни картинки за различна ориентация при една и съща ширина на екрана. И при това без да изразходвате безплатните мегабайти от плана на потребителя.
Малко полезни разширения
Вече споменах RIGC Responsive Images, официалното разширение добавящо поддръжка за отзивчиви картинки в WordPress. От версия 4.4 вече е част от самия WordPress, но можете да го използвате, за да активирате лесно picturefill или заради добавянето на подобрена компресия на картинките.
Докато работите върху сайта и се опитвате да прецените какви точно пропорции на картинките ще подхождат на различните екрани и какви размери картинки да генерирате, неизбежно ще ви се наложи да променяте набора от размери, които искате WordPress да генерира. Тогава на помощ идват разни разширения, които регенерират различните размери картинки. След няколко проби аз се спрях на Image Regenerate & Select Crop.
Когато започнете да качвате картинки бързо ще забележите, че автоматичното оразмеряване не винаги работи добре и често ще имате нужда ръчно да отрежете картинка така, че да се вижда най-добре дадена част от нея. Тук на помощ идва Manual Image Crop – това разширение ви позволява ръчно да изберете как да се отреже всеки регистриран размер на картинката.
Започва строителството на пасивна къща в кв. Коматево на гр. Пловдив
от Архитектурно студио АрхеОмачът и сиренето от Черничево влязоха в световния каталог Ark of Taste
от Георги СтанковНаправихме първата рекламна листовка за Черничево
от Георги СтанковПасивната къща работи за собственика си
от Архитектурно студио АрхеРазрешение за строеж получи сградата на Александра Аудио. Започваме организация на строителството
от Архитектурно студио АрхеВино, бавно хранене, зашеметяващи гледки и енергийна независимост
от Архитектурно студио АрхеЧрез мързел към прогрес – SalixOS
от LindeasБез да се спирам на по-подробно ревю, ще споделя накратко някои наблюдения от търсенето ми на “непосилната лекота” на дистрибуциите. След една серия от безуспешни тестове на често обозначаваните за най-леки дистрота – Puppy, Antix, Bodhi, LXLE, *buntu-та и поне още половин дузина в този списък, в търсене на нещо наистина “light” – попаднах на “върбата”, т.е. на SalixOS. Това се оказа базирана на Slackware дистрибуция, използваща дори неговата номерация на версиите (към момента 14.1), създадена от бивши разработчици на Zenwalk. За тези, които се изкушават от време на време да прелистват DistroWatch е ясно, че напоследък настанаха тежки времена за дистрото на французина Жан-Филип Гилмен, като проектът напредва с доста бавен ход. За сметка на това Salix набира сякаш по-голяма видимост, а зад всичко това стои основно интернационалният екип на Йоргос Влахавас, Сирил Понтвю, Пиерик Ле Брюн и Торстен Мюлфелдер.

Вероятно ще се запитате на какво може да се дължи този прогрес. Преди всичко на “ленността” е отговорът. Такъв е и девизът на дистрото – “Линукс дистрибуция за мързеливи Слакъри”! Ако не сте “die hard” фен на чистотата, Salix може да ви се понрави. Това, което най-вече очарова е изключително удобната комбинация от “ползваемост” и “лекота”. За доста стария хардуер (Dell Optiplex GX150), на който “лепнах” Salix, това беше търсеното и желано предимство .
Макар, че стандартният десктоп на дистрибуцията е XFCE, аз изпробвах нещо още “по-така”, а именно Openbox изданието. На сайта на дистрото се предлагат 32 и 64-битови версии на операционната система, а iso-файлът се побира на едно CD (625 Мб), нещо много удобно при условие, че старата машина няма dvd-плеър, и не може да буутва usb-флашки. Инсталаторът е в текстови режим, но целият процес е доста лесен дори за новак. Без излишно “ровене” в конфигурационни файлове системата се инсталира много бързо, като предлага 3 режима на инсталация – пълен, базов и основен.
Препоръчителният режим, разбира се, е пълният, а с него хората от Salix са решили да олекотят максимално нещата след инсталацията. Те използват fbpanel в комбинация с SpaceFM за файлов мениджър. Макар с леко орязани възможности, панелът предлага всичко нужно, като отделните му модули се добавят, премахват и настройват чрез конфигурационния му файл, в домашната директория. SpaceFM обаче ми се стори доста неудобен за моя вкус и предпочетох да го заменя с PCManFM, който е сякаш малко по-подреден.
Инсталирането на пакети в Salix е лесно, особено за свикнaлите с Debian. Използваt се slapt-get и slapt-src, заедно с техните графични интерфейси Gslapt и Sourcery, чрез които се избягва умело “адът на зависимите пакети”. При инсталация по подразбиране има почти всичко нужно за основно ползване на дистрото, а разработчиците са вкарали и някои техни инструменти за допълнителни настройки – напр. за настройка на аудио картата и др. под. (вж. тук), достъпни и за “чистия” Slack. По техни данни те допринасят и значителна част код и поправки на грешки за Slackware.
Ако пък в Salix ви липсва някоя програма, в основното хранилище има добър набор от софтуер, като трябва да се има предвид, че дистрото следва KISS-принципа. В добавка, ако и в основното хранилище липсва нещо, под ръка е Sourcery, чрез който бързо може да се инсталира каквото ви е нужно от SlackBuild хранилищата.
Уикито и форумът на Salix са основният източник на информация за разрешаване на проблеми с ползването. Макар и да не са от ранга на Ubuntu форумите или уикито на Gentoo, от общността може да се получи бърз отговор на възникналите въпроси.
За пуристите от Църквата на субгения, които не харесат “Върбата”, но са я инсталирали вече, утешение може да бъде това, че Salix може изцяло да се обърне в чист Slack, в мрежата има описателни инструкции как бързо би могло да стане това. Като цяло това е една дистрибуция парадоксално за днешното време съчетаваща ползваемост и лекота. Разбира се, всичко е въпрос на вкус, както казват някои – така, че винаги “зад ъгъла” чака нещо по-добро…
