Ако потърсите примери за качване на файлове с PHP и cURL, ще намерите много, и кодът между тях не се различава. Общо взето изглежда така:

<?php
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_VERBOSE, 0);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible;)");
    curl_setopt($ch, CURLOPT_URL, _VIRUS_SCAN_URL);
    curl_setopt($ch, CURLOPT_POST, true);
    $post = array(
        "file_box"=>"@/path/to/myfile.jpg",
    );
    curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
    $response = curl_exec($ch);
?>

Този пример е от първия резултат при търсене в Google по въпроса. Обаче при мен той не сработи. Отсрещната страна непрекъснато връщаше 417 Expectation Failed. И кво не ти харесва сега? Кои точно очаквания останаха неизпълнени?

Пробвах какво ли не – разни допълнителни параметри към cUPL, добавях променливи към POST данните, опитах допълнително да подам Content type… Не става!

Значи проблема не е в заявката, а в отсрещната страна. Потърсих дали някой друг не е срещал подобен проблем, и се оказа, че да, проблемът е в отсрещния уеб сървър, който ползва Lighttpd. Значи, cURL праща заглавка Expect: 100-Continue към отсрещния сървър и очаква от него или да отговори със 100 Continue, или нищо да не отговори, при което cURL да продължи с изпращането на данните. Да де, ама разработчиците на Lighttpd са сметнали, че е най-добре да отговорят с 417 Expectation Failed. Проблемът има две решения. Едното е да накарате cURL да не изпраща заглавката, като добавите празна такава:

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

Другата възможност е да накарате Lighttpd да се държи прилично. След настоятелите молби на потребители на тоз уеб сървър е добавена конфигурационна променлива, която да промени поведението при получаване на заглавка Expect: 100-Continue. Просто в конфигурацията трябва да добавите този ред:

server.reject-expect-100-with-417 = "disable"

Аз използвах второто решение и смятам от сега нататък да добавям този ред на всички сървъри с Lighttpd, до чиято конфигурация имам достъп. Това ще спести доста време на други като мен да се чудят защо пращането на файлове с cURL или Flash не работи.

И двете решения на проблема са описани в системата за следене на бъгове на Lighttpd:

http://redmine.lighttpd.net/issues/1017

За това след като разучих възможностите на някои JavaScript API-да и HTML5 Offline Storage, реших да пробвам дали ще се справя и с пакетирането на web widget.

W3C Widgets / Opera Widgets

Web widget всъщност представлява zip архив, който съдържа в себе си HTML, JavaScript, CSS и други компоненти на едно уеб-приложение. След като потребителят изтегли пакета на своето устройство, било то мобилен телефон или компютър, приложението се инсталира локално и при зареждане файловете се зареждат от файловата система, а не от мрежата. По този начин дори и да имате нужда от огромни библотеки и още 200k ваш JavaScript, това не е проблем за потребителя, защото той ще ги изтегли гарантирано само веднъж.

W3C Widgets е официалната спецификация и както повечето други спецификации на W3C се развива доста бавно. Това обаче не е пречка пред Vodafone и Opera, който в сътрудничество са създали имплементация на текущото състояние на описанието. Най-лесният начин да пробвате за какво става дума е да отворите Opera и да отидете на http://widgets.opera.com/. Opera отваря .wgt файловете и ви дава възможност да ги инсталирате локално на компютъра, като дори създава връзки за стартиране в менюто с програми. На мобилен телефон нещата стоят малко по-различно. Vodafone предлагат свой мениджър за S60 (предполагам преинсталиран на техните телефони), който включва в себе си runtime компонент от Opera. Освен това можете да инсталирате Opera Widget Manager – наличен е за всички платформи, за които е наличен и Opera Mobile. Така направих и аз – недостатък е, че мениджъра на Opera не слага икони за стартиране в общото меню с приложения, а трябва първо да стартирате мениджъра.

Това, което аз исках да направя, е всъщност доста просто приложение – специфичен хронометър, който да има обратен брояч от 5 минути до 0 и втори обикновен хронометър. Работата е там, че ветроходните регати имат особена стартова процедура, защото няма как яхтите да се подредят на стартовата линия и да чакат стартовия сигнал. Вместо това съдията на регатата подава зрителни и звукови сигнали 5 минути преди старта, 4 минути минути преди старта, 1 минута преди старта и сигнал за самия старт. През това време яхтите се въртят привидно хаотично зад стартовата линия и се стремят така да преценят своята и на съперниците си траектории, та да се окажат с максимална скорост преди стартовата линия и в най-изгодна позиция. За това на шкипера на яхтата му е необходимо да знае точно колко време остава до старта, и да измери за колко време изминава разстоянието от някаква изходна позиция до стартовата линия.

И така, набързо скалъпих един HTML файл със всичкия необходим JavaScript и CSS вътре в него. Няма нищо секси в кода на самия хронометър, важното беше просто да работи. По-интересно ми беше самото пакетиране на web widget-а и дали ще има особености в работата на скрипта.

След като имах „приложението“, дойде ред на пакетирането. Както споменах вече, всичко което трябваше да направя, беше да създам един XML файл с описанието на джаджата, да архивирам файловете и да променя разширението на WGT. Ето моя config.xml:

<?xml version='1.0' encoding='UTF-8'?>
<widget defaultmode="fullscreen" modes="application">
    <widgetname>Sailing Chronometer</widgetname>
    <description>
        Simple chronometer for measuring
        the start time sequence of sailing races.
    </description>
    <network>public</network>
    <width>360</width>
    <height>480</height>
    <author>
    	<name>Milen Petrinski - Gonzo</name>
    	<link>http://greatgonzo.net</link>
    </author>
    <id>
    	<host>greatgonzo.net</host>
    	<name>sailingchronometer</name>
    </id>
    <icon>icon_128.png</icon>
    <icon>icon_64.png</icon>
    <icon>icon_32.png</icon>
    <icon>icon_16.png</icon>
</widget>

Няма да обясняван значението на всяко поле, ако имате съмнения, най-добре прегледайте документацията на сайта на Opera. Тук е мястото да спомена, че документацията на сайта на Opera всъщност се различава от тази на W3C. Opera развиват технологията с по-бързи темпове, като в последната версия на Opera Mobile за Android имат поддръжка и за някои WAC 2.0 Device APIs.

Освен това трябваше да направя и иконка за джаджата. За това използвах Icon Creator – приложение от Opera, чрез което лесно можете да се създават икони, като се комбинира изображение или някой от вградените символи, и фон със или без преливка и ефект на отблясък. За самата икона използвах изображение на хронометър, лицензирано под GPL. Освен размерите, препоръчани на сайта на Opera, направих и размери като за iPhone, защото нищо не пречи същия HTML файл да се зареди от уеб и да се сложи връзка на началния екран. За целта добавих и manifest файл, за да може файла да се кешира като HTML5 offline приложение. Пробвах го на Android, стана, приложението работи дори и без връзка към мрежата.

Symbian Web Runtime Widgets

Nokia са били така добри да предвидят в Symbian всичко необходимо за създаване на приложения само чрез стандартни уеб технологии. Но естествено са го направили по свой начин. Всъщност техните пакети се различават от тези на W3C / Opera по формата на XML файла и по това, че всички файлове трябва да са поставени в директория със същото име като самия пакет. А, и естествено разширението и mime-типът на файла е различен, нищо, че пак е обикновен zip архив.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Nokia//DTD PLIST 1.0//EN"
    "http://www.nokia.com/NOKIA_COM_1/DTDs/plist-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>DisplayName</key>
		<string>SailingChronometer</string>
		<key>Identifier</key>
		<string>net.greatgonzo.sailingchronometer</string>
		<key>MainHTML</key>
		<string>index.html</string>
		<key>Version</key>
		<string>0.1</string>
		<key>AllowNetworkAccess</key>
		<false/>
		<key>MiniViewEnabled</key>
		<false/>
	</dict>
</plist>

Nokia са се погрижили разработчиците, ползващи HTML и JavaScript да разполагат съ същите възможности за достъп до системата както и разработчиците на „native“ приложения. За целта те предлагат Nokia Platform Services – набор от API-та за достъп до телефона от WRT widgets.

Но за момента аз нямах нужда да се задълбавам в тази материя, още повече, че ако едно приложение разчита на тези API-та, то става не по-малко native от приложение, написано на Qt.

За да си улесня живота с пакетирането на два различни формата, си написах прост скрипт, с който да автоматизирам малко процеса:

#!/bin/bash

# W3C Widget / Opera Widget
zip sailingchronometer.wgt config.xml index.html icon_*.png

# Nokia Web Runtime Widget
mkdir sailingchronometer
cp info.plist index.html icon.png sailingchronometer/
zip sailingchronometer.wgz sailingchronometer/*
rm -rf sailingchronometer

BlackBerry WebWorks

Съвсем случайно попаднах на страничка, показваща как да се пакетират приложения, използващи HTML, JavaScript и CSS за телефони BlackBerry. От RIM са използвали за основа W3C Widgets, като са разширили XML манифеста с допълнителни неща, които са сметнали за необходими. Това поне на пръв поглед изглежда доста добре, защото би трябвало да посволи едно и също приложение да работи и на телефон BlackBerry (почти) без изменеия. Дали наистина е така не мога още да кажа, защото нямам достъп до такова устройсто, за да тествам резултата.

RIM също като Nokia предлагат доста допълнителни API за достъп до всички ресурси на телефона, което прави възможно разработването на всякакви приложения само с HTML и JavaScript.

Ето и връзки към приложението и пакетите:

• Sailing Chronometer
• Sailing Chronometer Opera Widget
• Sailing Chronometer Symbian WRT Widget

На OpenFest 2010 Радо изнесе доста интересна лекция, в която чрез примери показа как вместо да викаме функции, можем да накараме различните части от JavaScript приложението да си говорят чрез различни дефинирани от нас събития. И най-хубавото е, че това става чрез любимата ми библиотека jQuery и HTML5 data атрибути. И така след първия прототип се отдадох на преправяне на приложението. Малко доразвих идеята на Радо, като разделих събитията на групи според естеството им, а за групиране използвах префикс.

Започнах от функциите, които получават данни от 4sq. Щом се получават данни, имената на събитията следва да са data:нещоси. Така имах две събития: data:venues когато получа списъка с близки обекти, и data:user когато извлека данните на текущея потребител. За всяко от тях написах функция, която да показва данните в страницата, манипулирайки DOM. За да укажа какви събития предизвикват контролите (демек разните бутони / линкове), използвах атрибути data-action със стойности action:нещоси според нуждата. Но вместо да прикрепям отделна функция, което да обслужва onclick събитието на всеки бутон, делегирах функция за всички елементи с атрибут data-action чрез подходящ селектор. Допълнителните данни, които са необходими, също поставих в data атрибути. Нещо не се получи да си предам само данните, така че за да не се боря с event обекта, си предадох направо DOM елемента, който генерира събитието. По-натам ще оправим този не толкова сексапилен код. Явно все пак предаването на данните от data- атрибутите се е получило.

В случай, че се случи някаква грешка, възможните събития са error:http и error:other. В първия случай трябва да обслужа специално случая, когато прокси-скрипта върне статус 401 – това значи, че потребителя не се е аутентикирал, и се налага да го пренасоча към 4sq. Във всички останали случаи просто показвам съобщението за грешка.

След като свърших с преправянето, JavaScript кодът имаше две обособени и в голяма степен независими части. Първата е един обект, в който е затворена всичката функционалност, свързана с Foursquare. Другата част остана по-разхвърляна – в нея се извършва манипулирането на DOM и се обработват действията на потребителя. Самия код можете да разгледате тук – това е работещата версия, която търпи промени от време на време. Доволен съм от резултата – мога безпрепятствено да променям всяка от двете части на приложението – мога да реструктурирам обекта, отговарящ за връзката със сървъра, без да пипам частта, отговорна за интерфейса, както мога да променя изцяло интерфейса, без да се налага да правя промени в кода за връзка със сървъра.

За да обясня защо смятам, че атаптивния дизайн Е единствения уеб-дизайн, ще ви разкажа аз стигнах до същите основни похвати. Когато започнах да пиша в този блог тъкмо се беше появил Asus EeePC. Първата версия беше със 7 инчов екран с разделителна сподобност 800×480. И тъй като много ми харесваше тази джаджа и се чудех дали да не си купя, исках съответно сайтът ми да е използваем и на нейния екран. Да, ама повечето (почти всички) сайтове се правят за екрани 1024×768 пиксела и това важи и за темите за WordPress. Така че едно от първите неща, които направих с темата на моя блог беше да я направя да се свива и разпъва според размера на браузъра. Но бях ограничил ширината до 1200 пиксела, защото при по-големи ширини редовете ставаха твърде дълги и нечетими. След това заедно със стиловете за печат добавих и стилове за hendheld устройства. Това трябваше да осигури подходящ изглед за мобилни телефони и PDA устройства. Работата е там, че Apple повлякоха крак още с първия iPhone и всички мобилни браузъри след него не се съобразяват със стиловете за hendheld медия, а лъжат че са настолни браузъри, за да покажат колко добре се справят със съществуващите сайтове.

След време обаче научих, че в CSS3 е предвиден начин стиловете, които браузъра ползва, да бъдат подбирани не само по типа медия, но и по нейните характеристики. Първото нещо, което направих, беше да насоча стиловете за hendheld и към screen медия, ако ширината на браузъра е по-малко от 800 пиксела. След това седнах и написах кратка статия за това.

Да, ама от време на време като разпъна прозореца на браузъра върху всичките 1650 на 1050 пиксела на домашния монитор и много се дразнех на празните бели полета от двете страни на сайта. А с повечето сайтове положението е още по-зле, защото са с едно 200 пиксела по-тясни. И реших, че медийните заявки могат да се използват и за адаптиране на дизайна към много големи екрани. Накрая имах сайт, който е ползваем на малкия екран на мобилен телефон и в същото време се възползва максимално (макар и не по най-добрия начин) от пространството на голям настолен монитор. А, и след няколко месеца в A List Apart излезе статията на Итън Маркот.

След този дълъг и надявам се не много скучен увод да видим къде критиките към responsive дизайна издишат.

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

Сама презумпция, че обемът на трафика е от съществено значение само за мобилните потребители е абсолютно погрешна. В България може и да има съществена разлика в скоростите, защото не навсякъде има 3G покритие и мобилния интернет все още е екстра, докато доставчиците предлагат скорости над 5 мегабита, но по света съвсем не е така.

Често се изтъква факта, че ако даден елемент е скрит в стиловете за малки екрани, голямата картинка за фон все пак се зарежта. Ама не се прави така бе, хора! Ако фонът е поставен в стил, който важи само за големи екрани, браузърът на мобилния телефон няма да тегли картинката.

Медийните заявки не оптимизират съдържанието за мобилните потребители и те пак трябва да свалят пълния размер на сайта.

А защо смятате, че обикновения сайт трябва да е претрупан с неща, които не са пряко свързани с основното съдържание на страницата и само отвличат вниманието на потребителите от това, заради което са дошли на сайта? Защо е допустимо да отрупате страницата с реклами и освен това да накарате потребителя да цъка найсе пъти през междинни рекламни страници и банери, отварящи се върху основното съдържание?

Ако един обикновен, настолен ако щете, сайт не е фокусиран върху основната цел, заради която потребителите го посещават, как очаквате мобилния вариант да остане фокусиран?

Адаптивния дизайн не взима предвид мобилния контекст.

Колкото повече чета за този мобилен контекст, толкова повече се убеждавам, че това е някаква пълна глупост. Презумпцията, че потребителят на мобилния телефон е задължително в движение и бърза да намери някаква информация на сайта ви догато се шмуга между тълпата излизайки от метрото, е изсмукана от пръстите. Повечето хора използват iPhone-ите си за браузване докато си пият кафето в Старбъкс или вкъщи пред телевизора. Това къде се намира потребителя, с каква скорост се движи, или колко е шумно не определя целта на посещението му на вашия сайт. Ще ви дам примери: Бизнесмен си седи в удобното кресло на частния самолет, летейки с 1000км/ч над Ню Йорк и разглежда сайт за резервации на самолетни билети на своя iPhone, защото планира семейната почивка след 2 месеца. Или пък обикновен служител, заседнал в задръстване заради катастрова на магистралата край Ихтиман отваря същия този сайт на своя лаптоп (щот шефа не му е купил умен телефон), защото след 5 минути има среща в кол-центъра на фирмата, изнесен за по-евтино в Пловдив.

И след тези излияния, нека ви разкажа как смятам, че трябва да се използва техниката на адаптивния дизайн. Първо започваме от най-основните неща, които ще са общи за всички размери на дисплея – типографията, цветовата схема и т.н. След това чрез медийна заявка можем да опишем специфични стилове за малки екрани със съвременен браузър, ако искаме да добавим нещо специфично за тях – малки картинки за фон например. После идва ред на по-големите екрани – пак затворени в медийна заявка поставяме допълните стилове, които оформят разположението на елементите по страницата за големи екрани. В този блок включваме и @font-face декларациите, и фоновите картинки, ако не искаме да товарим мобилните устройства с допълнителен трафик. Що се отнася до изображенията в сайта, варианти много в зависимост от целта на сайта. Ако картинките са особено важна част от съдържанието (фотоблог примерно) и не са твърде големи, можем да ги сервираме както са и да ги намалим със CSS. Ако пък са само за илюстрация на текста и държим да намалим трафика, можем да сложим в сайта картинки с малък размер, които след зареждане на страницата да заменим с по-големи само за големи екрани чрез JavaScript.

Адаптивния дизайн не е техника за пригаждане на десктоп-сайтове към мобилни браузъри. Адаптивния дизайн е техника за цялостен дизайн на сайтове. През XXI век, когато екраните, на които потребителите ползват уеб, варира от 200 до 2000 пиксела адаптивният дизайн Е начинът на направим сайта си достъпен за всички.

Ето и малко връзки към статии по темата, които намирам за особено полезни:

• Mobile First
• Context
• ★ I don’t care about Responsive Web Design
• Using Media Queries in the Real World
• Windows mobile media queries
• Respond
• 320 and Up
• Rethinking the Mobile Web

Както всяка уважаваща себе си услуга за гийкове, и FourSquare предлага API, за да могат разни асоциални разработчици да прекарват свободното си време в създаване на безполезни приложения. Първо започнах от различни описания на oAuth. Както може би знаете, това е начин потребителите да разрешат достъп на външно приложение до профила им в дадена услуга без да предоставят името и паролата си на приложението. От гледна точка на потребителя процеса е доволно прост – потребителя бива препратен към сайта на услугата, където след като се аутентикира и разреши достъп на приложението, бива препратен обратно към сайта на приложението. Обаче гледната точка на разработчика, прилагащ на практика механизъма, нещо не ми стана достатъчно ясна.

Въпреки, че изчетох доста текст за oAuth, а API-то на FourSquare не е висша математика, накрая просто използвах готова библиотека. Като начало реших, че най-лесно и бързо ще реша проблема със same domain policy като напиша прокси-скрипт. За него няма да пиша подробно, доста е грозен, но за сега работи. Използвах ето тази библиотека за връзка с API-то на FourSquare. При правенето на скрипта исках да избегна нуждата от база данни – едно, че исках да е възможно най-прост, и второ, че не желая да се занимавам със съхраняване на данни. По тази причина и защото не можах да схвана значението и смисъла на параметрите, с които борави oAuth (за това спомогнаха неясните за мен примери, в които с едни и същи имена бяха кръстени очевидно различни параметри), реших като начало да разчитам на сесиите в PHP. Неудобството беше, че при всяко рестартиране на браузъра аутентикацията трябва да се извърши наново. Съществената особеност е, че oAuth API-то на FourSquare предлага(ше) възможност потребителя автоматично да бъде пренасочен обратно към приложението, ако вече веднъж е разрешил то да достъпва данните му. Така след първия път, когато трябва да напише потребителското си име и паролата в сайта на FourSquare, потребителя страда само от малко пренасочвания. На Стоян няма никак да му хареса, но пък така не се налага прокси-скриптът ми да пази oAuth токените на потребителя в база данни.

Всъщност преди две седмици изтеглих нова версия на библиотеката, която вече работи с новата версия 2 на FourSquare API, при което естествено се наложи да пренапиша почти изцяло всичко. В примерите обаче след като завърши процеса на oAuth аутенкикация параметърът, достатъчен за по-нататъшната работа беше един и се запазваше като бисквитка. Е, щом в примерите е така, прецених, че и аз мога да постъпя по същия начин и потребителите (аз!) няма да се налага да чакат досадните препращания при първоначалното зареждане на приложението. Освен това добавих малко по-добро обслужване на грешки (е, има още какво да се желае).

И така, набързо скалъпих един доста грозен JavaScript, който след като определи местоположението на потребителя, извлича близките места от FourSquare и ги показва като списък. До името на всяко място поставих бутон, чрез който потребителя да се „чекира“ в това място. Използването на приложението е песен в сравнение на другите приложения за Symbian. Обаче за да го покажа на хората, не стига то да работи, кода трябва да е малко по-елегантен, че да не се срамувам от него. Трябваше ми нещо секси, и си спомнях, че Радо Станков вече ни е показвал нещо наистина възбуждащо. За това как го приложих обаче ще ви разкажа в следващата част.

Връзки:

• Първата версия на Foursquare API, с която започнах
• Foursquare APIv2
• oAuth от първа ръка

GeoLocation API

Въпреки че не е част от спецификацията на HTML5, GeoLocation API често се споменава заедно с него и е естествена част от NEWT. Позволява ни чрез съвсем малко JavaScript да определим местоположението на потребителя. Отворих една страничка, демонстрираща възможностите на GeoLocation и бях изумен от точността – точката върху картата беше на 100 – 200 метра от вкъщи. Напълно достатъчно за нуждите ми.

Да видим как става номера:

if (navigator.geolocation) {
	navigator.geolocation.getCurrentPosition(
		function (position) {
                    // имаме местоположението на потребителя: position.coord.lat и position.coords.lon
		},
		function (error) {
                    // грешка при определянето на местоположението
		}
	);
}
else {
    // браузъра не поддържа GeoLocation API
}

Можете да разчитате, че успешно ще установите мястото на потребителя, стига той да ползва достатъчно нова версия на Firefox, Safari, Chrome или Opera. Но за мен е интересно дали ще работи на мобилния ми телефон. Моят парашут се отвори, когато инсталирах Opera Mobile 10.1, а собствениците на iPhone или телефон с Android могат да бъдат локализирани и без нужда от инсталиране на допълнителен софтуер. Единствената особеност е, че някои устройства с Android 2.1 изискват да е включен GPS приемника, въпреки, че не разчитат на него (пробвах с Globul Q1 SE).

Как работи GeoLocation?

Добре де, а как браузъра определя местоположението без GPS, ще попитате вие? Браузърите използват няколко метода, чрез които определят местоположението в зависимост от наличните GPS и мрежови устройства.

Когато има наличен GPS, браузърите на мобилни телефони могат да използват данните от него, за да установят с голяма точност местоположението на потребителя. Този подход работи на телефони с Android OS и на iPhone, но WebKit браузърат на моята Nokia 5800 не поддържа въобще GeoLocation API, въпреки, че телефона има GPS.

Когато няма GPS, или той не може да установи местоположението, браузъра използва други методи. Първата възможност е чрез информация от GSM мрежата – клетките са с известно местоположение и чрез изчисление на базата на силата на сигнала от различните клетки местоположението може да се установи с достатъчно голяма точност. Това е всъщност една от функциите на A-GPS устройствата, вграждани в мобилните телефони. Другата е изтеглянето на алманаха с местоположението на сателитите през Интернет, което ускорява установяването на местоположението.

Когато и този метод не е наличен, има още един начин местоположението да се установи със задоволителна точност. Има различни фирми, които обикалят по улиците с автомобили и събират информация за силата на сигнала на различните WiFi мрежи. След това може лесно по обратния път да се установи къде се намира дадено устройство по списъка с видими мрежи и тяхната сила. Това е и основния метод, който използват Opera и Firefox, като и двата браузъра правят заявка до услуга на Google за това. За Opera това се разбира лесно – първото нещо, което браузъра ви пита, преди да върне резултат за местоположението, е дали сте съгласни с общите условия на Google за тази услуга. За Firefox го разбрах, докато следях заявките от браузъра чрез разширението TemperData.

И последният възможен метод за установяване на местоположението е чрез GeoIP. Това е най-неточния метод – в най-добрия случай местоположението ще е с точност до град или квартал (дали?), което са от няколко километра до десетки километри. А в най-лошия случай GeoIP базата данни може да позиционира потребителя в съвсем друга държава или континент.

По-подробно за методите на API-то

Но да се върнем към JavaScript и GeoLocation API. В горния пример показах как в общи линии се използва методът getCurrentPosition. Този метод връща текущата позиция на браузъра, като приема три аргумента. Първият е callback функция, която да се изпълни при успешно установяване на местоположението, и която приема като параметър обект, описващ местоположението. Вторият параметър е callback функция, която да се изпълни в случай на грешка и приемаща като параметър обект, който я описва. Третият параметър, който съм пропуснал в примера, е обект, чрез който се подават различни настройки към метода. Втория и третия аргументи могат да бъдат пропуснати.

if (navigator.geolocation) {
    var options = {
        enableHighAccuracy = true, // Ако е истина, изисква възможно най-точни резултати
        timeout = 5000, // Колко време да чакате да получите позицията, в милисекунди
        maximumAge = 10000 // Колко стара позиция сте склонни да приемете
    }
    navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options);
}
else {
    // браузъра не поддържа GeoLocation API
}

function successCallback(position){
    alert(position.coords.latitude + ', ' + position.coords.longitude);
}

function errorCallback(){
    switch (error.code) {
    case error.TIMEOUT:
        alert ('Timeout');
        break;
    case error.POSITION_UNAVAILABLE:
        alert ('Position unavailable');
        break;
    case error.PERMISSION_DENIED:
        alert ('Permission denied');
        break;
    case error.UNKNOWN_ERROR:
        alert ('Unknown error');
        break;
    default:
        alert(error.message);
    }
}

Обектът, описващ позицията на устройството има следния вид:

{
    timestamp: [DOMTimeStamp],
    coords: {
        latitude: [double],
        longitude: [double],
        altitude: [double],
        accuracy: [double],
        altitudeAccuracy: [double],
        heading: [double],
        speed: [double]
    }
}

Ако браузърът няма възможност да установи височината, посоката или скоростта, стойността на съответното свойство трябва да е null.

Освен, че позволява да установим текущата позиция на браузъра, GeoLocation API има метод, чрез който да следим за промени на местоположението. Методът е watchPosition и се използва по същия начин както и getCurrentPosition. Разликата е, че callback функциите ще се изпълняват всеки път, когато устройството прецени, че има промяна в местоположението, и връща като резултат число подобно на setTimeout и setInterval. Следенето на позицията може да бъде прекъснато чрез метода clearWatch:

if (navigator.geolocation) {
    var watch = navigator.geolocation.watchPosition(successCallback, errorCallback, options);
    setTimeout(function(){
        navigator.geolocation.clearWatch(watch);
    },600000);
}
else {
    // браузъра не поддържа GeoLocation API
}

Заключение

Някои от вас може би се чудят за какво му е на сайта да знае къде се намира потребителя, други вече си представят как ще следят жената или разтресения от пубертета син, а Бого ще е загрижен за личната неприкосновеност на потребителите (и с право!).

Да започнем от личната неприкосновеност – според спецификацията на W3C браузъра не трябва да издава местоположението си без изричното съгласие на потребителя. Тествах поведението на Firefox, Opera и Chrome на десктоп (Linux и Windows) и на браузърите на iPhone, няколко Android устройства, и на Opera Mobile на Symbian, и всички те спазват това изискване. Нещо повече, на iPhone трябваше да разреша някаква опция, забита из настройките на телефона, за да сработи приложението ми.

GeoLocation API ни позволява да навлезем в територия, запазена до скоро само за традиционните приложения. Вече имам идеи за няколко такива, повтарящи функционалността на приложения за Android или iPhone, но работещи на всякакви устройства без нужда от пренаписване. Освен това вече можем да предложим съдържанието по различен начин, знаейки, че потребителят се движи и вниманието му не е изцяло заето със сайта. Можем да предложим по-адекватни резултати от търсенето на „магазин за сърф“, знаейки, че той е в Бургас, а не във Варна. Следващата граница е вашето въображение.

Не, не вярвам, че някое старо момче
ще се съгласи да им каже мерси
защото днес е с дълги коси.

Ей на, намериха се. И то не кои да е, а най-успелите, онези, които ни даваха надежда, че и в България има място за рок. Групата, която изпя „Аз не съм комунист и никога няма да бъда!“ сега приема почести от агент Гоце!

Ако не сте се сетили за какво става дума, новината на деня е, че президентът е наградил Щурците с ордени “Св. св. Кирил и Методий”. Въпросът не е заслужават ли Щурците ордени или не. Естествено, че са заслужили много повече за това, че в продължение на 20 години свиреха рок в комунистическа България, че вдъхновяваха младите хора (и мен включително), че чрез музиката си ни даваха глътка свобода, когато ни беше нужна. Обаче от агент Гоце ли чакаха награда?

Не мога да не направя паралел с едно друго събитие, случило се точно на днешния ден през 1965 година. Преди 45 години кралица Елизабет II награждава The Beatles с ордените на Британската империя. Разликата с онова събитие е, че Джон Ленън връща своя в знак на протест срещу подкрепата на Британското правителство на войната във Виетнам.

Защо Щурците нямаха доблестта да откажат ордените, връчени им от бивш агент на Държавна сигурност?

Идеята естествено ми дойде докато гледах подобна галерия, демонстрираща възможностите на CSS3. Поработих доста по моя вариант, за да го направя да изглежда добре дори и на по-стари браузъри или на малкия екран на мобилно устройство. Освен това трябваше да измисля някаква хитрина, за да изглеждат снимките разхвърляни, защото списъкът се генерира динамично и няма как да ги разхвърлям целенасочено.

За да постигна желаната от мен визия използвах няколко свойства, коите вече имат доста добра поддръжка в текущите или бъдещите версии на основните браузъри. Арсеналът включва селектори :nth-child(), box-shadow, трансформации, медийни заявки, RGBa цветове. За съжаление се наложи да напиша доста еднотипни редове с декларации, различаващи се само по префиксите за различните браузъри, но това е неизбежно ако искаме да се насладим на най-новите възможности на CSS.

Първата стъпка както винаги е добре структурирания код. Блокът с картинките, които исках да украся изглежда така:

<ul class="polaroids">
    <li>
	<a href="" title="">
		<img src="" alt="" />
		<p></p>
	</a>
    </li>
    <li>
	<a href="" title="">
		<img src="" alt="" />
		<p></p>
	</a>
    </li>

...

</ul>

Доста проста структура, използвал съм HTML5, за да мога да заградя с един a елемент самата картинка и параграфа с описанието. Основните стилове за оформянето на галерията също не са нищо особено:

ul.polaroids {
	clear:both;
	width:90%;
	margin:60px auto;
}

ul.polaroids li {
	display: inline;
	vertical-align:top;
	width: 200px;
}

ul.polaroids li a {
	display: inline-block;
	padding: 10px 10px 20px 10px;
	width: 180px;
	margin:15px;
	border: 1px solid #BFBFBF;
	background-color: white;
	vertical-align:top;
	text-decoration: none;
	color: #333;
	font-family:Georgia,"Lucida bright","Times new roman",serif;
	z-index: 0;
}

.polaroids li a:hover,
.polaroids li a:focus,
.polaroids li a:active {
	outline: 5px solid #ddd;
}

Единственото, което може да ви се стори странно е изборът на стойности на свойствата display на li и a елементите. Те са избрани така, че снимките да се подреждат естествено в редове и колони и да могат да се застъпват, когато започнем да ги „разхвърляме“ по екрана. Друго, на което държа да обърна внимание е последната декларация. Дефинирал съм стилове за псевдокласовете :hover, :active и :focus, за да сигнализирам на потребителите, ползващи само клавиатура, кой е активния елемент.

Сега вече идва трудното. Искаме да завъртим снимките на различни ъгли, да намалим в различна степен размерите и да им пуснем лека светлосянка. Когато потребителят премине с мишката над някоя снимка (или я фокусира с клавиатурата), искаме тя да се завърти хоризонтално, да е с нормалният си размер за да изглежда добре, и светлосянката да се измести и изсветли, така че да създадем ефект все едно сме я дигнали над масата.

Нека на сцената излязат CSS3 трансформациите сега!

-webkit-transform: rotate(10deg) scale(.7);
-moz-transform: rotate(10deg) scale(.7);
-o-transform: rotate(10deg) scale(.7);
transform: rotate(10deg) scale(.7);

Както виждате, една и съща декларация е повторена четири пъти. По веднъж за WebKit, Mozilla и Opera с префикс и една декларация без префикс за браузърите, които ще поддържат това свойство според спецификацията (IE9 например). Тук съм приложил две трансформации наведнъж – завъртане на 10 градуса по часовниковата стрелка (rotate(10deg)) и намаляване на елемента до 70% от първоначалните размери (scale(.7)). Другите възможности за трансформиране са преместване (translate), наклоняване или изкривяване (skew) или подаване на матрица на трансформацията. Но най-добре прегледайте спецификацията на модула за 2D трансформации.

Това добре, обаче как да създадем впечатление за разхвърляност? Идеята, която ми хрумна е да задам пет различни трансформации като използвам :nth-child() псевдокласове. Ако броят снимки на ред не съвпада с броя варианти на трансформациите, това ще създаде впечатление за неподреденост. Чрез псевдокласа :nth-child можем да избираме елементи, чийто индекс в списъка с дъщерни елементи отговаря на формулата an+b, където n е индекса на елемента, започвайки от 0. В моя случай селекторите са :nth-child(5n), :nth-child(5n+1) до :nth-child(5n+4). Освен различни ъгли на завъртане и различен мащаб им зададох и различен z-index, за да подсиля усещането за разхвърляност.

Първоначално имах идея да направя два набора от правила – един набор от примерно 5 различни ъгъла на завъртане и друг набор от 7 различни мащаба. Този подход естествено не сработи, но ще оставя на вас да помислите защо.

Какво остана? Да опишем свойствата на :hover, :active и :focus псевдокласовете като зададем по-голям z-index, нулеви стойности на транформациите и по-широка светлосянка.

А, светлосенките! Естествено, на помощ идват box-shadow и RGBa. Свойството box-shadow описва светлосенките, като се задават последователно отместването по X, отместването по Y, ширината на зоната на разсейване на сянката и цвета и. За да са полупрозрачни сенките използвах RGBa, всички браузъри поддържащи едното, поддържат и другото, така че не е проблем да ги смесим.

И накрая финалните щрихи. Добавих плавни преходи между различните състояния чрес свойството transition със всичките му необходими префикси, накарах снимките да се застъпват, като подадох отрицателни отстояния (margin) и се погрижих всичките тези глезотии да не развалят вида на галерията в по-стари браузъри или на малките екрани на телефони или други преносими устройства. За тази цел използвах медийна заявка. Отново разчитам на факта, че всички браузъри, разбиращи CSS3 трансформации, ротации, транслации, пермутации… опа, май се увлякох… та те също така разбират и медийни заявки. Като направя медийната заявка да е насочена към екрани по-широки от 700 пиксела успешно обхващам всичко по-голямо от iPad, що е съвременен браузър. Останалите могат да си припомнят онази реплика от История на света – сцената в която се обсъждаше бюджета на империята и отношението на сенаторите към по-неплатежоспособните им съграждани.

Завършената галерия служи да споделям снимки с приятели, а можете да разгледате и пълният CSS, ако желаете.

Като завършек ще кажа, че можете успешно да използвате всякакви CSS3 екстри, за да направите сайта си атрактивен, без да нарушавате потребителското изживяване за потребителите на по-стари браузъри. Медийните заявки са идеален инструмент за прогресивно подобряване.

Не можах да уцеля входа на Елиеф Център от първия път, но пък не се наложи да ползвам жокери и след лека заобикалка се намерих пред рецепцията. Организаторите се бяха погрижили за нас, бедните хорица, дето хич не обичаме да ставаме рано, и бяха осигурили кафе (и чай), та си сипах едно голямо се отдадох на социализация. После дойде време и за лекциите, та заедно се понесохме към залата да търсим места. Явно всички чакаха последния момент, защото места имаше разни, но с Бого и Дечо стратегически се настанихме близо до контактите. Когато започна първата лекция, залата вече беше почти пълна.

Повечето лекции ми бяха интересни и полезни, понякога и забавни. Освен румънските лектори, които явно не бяха подготвени за събитието, всички други говориха добре и дори презентациите за SEO не можаха да ме изгонят от залата. Мислех да пиша по-подробно за отделните лекции, но реших да разкажа само за тези, които най-много ми харесаха (разбирай половината).

Първата техничарска презентация беше на Константин Данков. Макар и не съвсем стройно, Мързеливеца успя да обясни как се създава дъщерна тема на K2. Беше ми адски полезно, защото все не остава време да прочета за родствени връзки между темите на WordPress.

Стефан Кънев както винаги изкърти. Не знам, имам чувството, че и за квантова механика или термодинамика да седне да говори, пак ще ми е интересно. А той просто систематизира нещата, до които всеки блогър (опитващ се да) пише на професионална тема достига.

Еленко говори увлекателно и като цяло презентацията му беше забавна. Описа по неговия си неповторим начин промените, настъпили в блогосферата в последно време. Изводът е, че плявата се е преместила във facebook, а машините за линкове вече спамват Twitter.

Бого направи интересна презентация за това как да искарваме пари, работейки с WordPress. Освен, че разказа интересни неща и говори много увлекателно, спечели поне моето възхищение с факта, че презентацията беше изградена изцяло с HTML5 и CSS3 (за да се насладите пълноценно ще ви трябава Firefox 4). Бого, имаш бира от мен за това!

Хедлайнер на WordCamp беше Дзвер, който обясни какво не трябва да се прави, ако искаме блогът ни да ни надживее. Надявам се никога да не ми се случват нещата, описани от него. Което ме подсеща да ида да си направя бекъп.

Въпреки, че и двата стандарта са все още в различни фаза на незавършеност, отделни техни модули не само са придобили стабилен вид, но и вече имат широка поддръжка в различните браузъри. А ако толкова много държите на IE, много от нещата или деградират елегантно, или има има специфичен начин за постигане на ефекта. А и нали не вярвате, че сайтовете трябва да изглеждат еднакво във всеки браузър?

И така, да видим няколко неща от HTML5 и CSS3, които можем да използваме сега и веднага.

Нови типове input елементи

HTML5 дефинира една купчина нови типове елементи за вход от потребителя. Специални елементи за адрес на сайт или електронна поща, за въвеждане на числа чрез бутончета нагоре – дадолу или чрез плъзгач, за въвеждане на часове и дати. И няма ама абсолютно никакъв проблем да ги ползвате, защото старите браузъри вместо непознатите типове input ще използват поле за текст. Ако много държите, с малко JavaScript можете да оправите нещата. А предимствата са, че потребителите на съвременни браузъри ще имат по-добро потребителско преживяване. Например собственицитне на iPhone (може би и други) ще виждат клавиатура, състояща се само от позволени знаци за въвеждане на URL или пощенски адрес.

Елементите video и audio

Вече всички настолни браузъри освен един поддържат чудесно новите елементи за публикуване на видео или аудио в уеб-страници. Въпреки, че има различия в поддържаните формати, с много по-малко усилия можете да споделите последното забавно клипче от снощния купон. И да не забравяме, двата най-големи сайта за публикуване на видео – YouTube и Vimeo вече поддържат HTML5 видео, Vimeo дори са разработили плеър за вграждане на техните видеа в други сайтове.

data- атрибути

Един чудесен начин да добавите допълнителни данни към DOM елементите във вашето уеб приложение. Стандартът предлага възможността да добавите произволен брой атрибути, започващи с data- и дава възможност за достъп до данните, записани в тях чрез свойството dataset на DOM елемента. Вече няма нужда от безброй скрити и явни елементи и нестандартни атрибути, поставени само за да дадат достъп до някакви данни чрез JavaScript.

CSS3 selectors

CSS3 дефинира доста интересни начини за насочване на стилове към елементи от страницата. Особено интересни са новите псевдоелементи, чрез които можете да насочите стиловете не само към първия дъщерен елемент (:first-child), но и към последния (:last-child) и дори към всеки елемент, чийто индекс отговаря на израз от типа a*n+b (:nth-child()).

Светлосенки чрез text-shadow и box-shadow

Искате светлосенки? Няма проблем, CSS3 е насреща! Ама браузърите на някои потребители няма да ги изобразят? И какво от това, някои потребители нямат възможност да ги видят, но до скоро настоявахте да ги карате да си свалят картинките въпреки това.

Цветове в RGBa

Можете да направите фона на даден елемен полупрозрачен, или пък текста в него, или пък контура, както демонстрирах вече. Вместо PNG изображения, които да забавят зареждането на сайта, можете да постигнете невероятни ефекти само с помощта на RGBa.

Заоблени ъгли чрез border-radius

Стига вече с тези плъзгащи се врати, със CSS3 можете да постигнете същия ефект и много повече. По един или друг начин свойството се поддържа още от Firefox 1 и ако още не сте го използвали, вече е крайно време.

CSS3 Media queries

Пробвали ли сте как изглежда сайта ви на голям монитор? А на мобилен телефон или iPad? Не е както си го представяхте, нали? С помощта на CSS3 media queries можете да приложите различни стилове в зависимост от разделителната способност, ориентацията, или броя цветове, които поддържа екрана. Само с малко допълнителен CSS можете да пригодите сайта си за мобилни устройства и екрани с висока резолюция. Адаптивния дизайн е новото черно!

Шрифтове с @font-face

О, щях да забравя, @font-face! Това беше горещата тема преди половин или една година, нали не сте забравили? Все едно дали ще предпочетете удобството на някоя от многото услуги, предоставящи шрифтове за уеб или ще публикувате шрифтовете сами. Време е да се освободите от оковите на web-save шрифтовете и да покажете, че типографията в уеб има бъдеще.

След всичко това следва и задължителния списък с помощни материали:

• HTML5
• Модулите на CSS3
• HTML5 Doctor
• Dive Into mHTML5
• CSS3.info
• A List Apart
• Или просто потърсете