Webdesign

Na Interval.cz vyšel můj článek o Zend’s PHP 5 Coding Contest, první ze série pěti článků. S Vilémem Málkem jsem domluven i na napsání několika článků o JEditu a PHPEclipse.

Na interval.cz se objevila další perla do kritiky webu, a to sice dráhaři.info. Nechci se zde (opět) zabývat tím, jak probíhá selekce do kritiky webu, už jsem k ní měl dříve zhruba 1.000 výhrad, zabývat se chci webem dráhaři.info samotným.

Titulní strana tohoto webu nás přivítá originální volbou kódování Windows-1250 nebo ASCII. Hm, zajímavé, co to asi je, řekne si mašinfíra? Neví, tak na něco z toho klikne, a ocitne se zde.

Nevím jak Vy, ale mě trvalo dost dlouho, než jsem přišel na to, že ty prťavé horní (okopírované Pixyho) ikonky jsou ve skutečnosti hlavní navigační menu, a ne ikonky pro RSS exporty a W3C validátor.

Pod těmi ikonkami je potom i nějaký obsah, nicméně, kdo se k němu má dostat??

Nechápu, proč se amatéři snaží dělat věci sami, a špatně. Nejedná se ani tak o to, že je tam nevalidní HTML kód, to je vcelku jedno, katastrofa ale je, že ten web nesplňuje ani z jednoho procenta zásady přístupnosti, použitelnosti, nehovoře o optimalizaci pro SEO, a postrádá rovněž základní funkce, které by takový web měl mít.

Je to prostě zmatený shluk textu, ve kterém se čtenář nemá šanci vyznat.

Přitom by si autor zmíněného webu, webdesignový nedouk, mohl stáhnout zdarma BLOG:CMS, získat zdarma hosting na pipni.cz, a během deseti minut mít systém, který umí články rozčlenit do kategorií, obsahuje diskusní fórum mašinfírů a fotogalerii jejich mašinek, je od počátku navržen jako XHTML 1.0 STRICT validní, jako přístupný a použitelný web, s možností prohledávání článků, s jasně danou navigací, s exportem a tiskem článků, s optimalizací pro SEO, s WYSIWYG editorem, a s řadou dalších věcí.

Nerozumím tomu, proč amatéři, kteří se webdesignu nechtějí věnovat profesionálně, nepoužijí řešení profesionálů, a raději si to doma mastí spokojeně, a zcela špatně, na koleně, a svůj web navíc drze přihlásí do “kritiky webu”… To nečetli kritiky předchozí???

UTF-8 je geniální kódování. Pokud programuji BLOG:CMS, musím pochopitelně počítat s tím, aby onen zdrojový kód běžel bez problémů nejen v Česku, ale i (třeba) v Rusku, Japonsku či Číně. Kdekoliv.

Mírný problém je sice se zpracováním UTF-8 řetězců v PHP, zejména funkce představené ve stařičkém PHP 3.x s UTF-8 vůbec nepočítají, například takové funkce substr() či strstr() pracují bajtově, a rovněž tak řada dalších funkcí, nicméně, stále je to menší problém, než počítat ve Vašem kódu s desítkami různorodých znakových sad.

Nové funkce v PHP 4.3/5.0 navíc již s UTF-8 počítají, včetně funkcí / metod pro práci s XML, neboť UTF-8 je implicitní kódování pro XHTML / XML.

Problémem není ani editace zdrojového textu v UTF-8 na libovolné platformě, jeden z nejlepších programátorských editorů, JEdit, nativně pracuje s UTF-8 a je psaný pod Javou, tudíž běží na každém OS, kde je implementována JVM. Pár lidí používá na Windows rovněž PSPad, nicméně, ten se pro rozsáhlejší projekty skutečně nehodí, a to nejenom proto, že jeho podpora UTF-8 je jen částečná (rozumějte, velice nedostatečná).

Řada nových Linuxových distribucí (SUSE 9.1, Fedora Core 3, MDK 10.1) se rovněž implicitně instaluje s nativní podporou pro Unicode / UTF-8.

Ještě před rokem jsem dělal projekty ve windows-1250, windows-1251, windows-1252, iso-8859-2, iso-8859-1, prostě podle potřeb daného projektu, a řešil jsem řadu problémů při konverzích, a dnes vlastně ani nevím proč jsem už dávno nepoužíval UTF-8. S přechodem na UTF-8 se řada problémů, které člověk s různými kódovými stránkami měl, automaticky vyřešila.

Nebylo by od věci zrušit veškeré existující kódové stránky a schémata, a používat jen UTF-8. Spousta věcí by se dělala mnohem snadněji.

Nenapadá mě rozumný důvod, proč vlastně něco jiného než UTF-8 ještě používat…

PS: ne, úspora pár bajtů a přenosové kapacity ten důvod proti UTF-8 není. Internet zahlcují P2P sítě, ne používání UTF-8.

Ne, nepotřebujete na to žádný log, a poznáte přesto přesně datum a čas, kdy Vás google.com indexoval. Stačí na Vaši stránku umístit datum a čas jejího vytvoření (to dělám v mém případě, protože se statické stránky vytváří redakčním systémem automaticky, po 30 minutách), nebo přímo aktuální datum a čas, a potom se podíváte na cache stránky google.com pro myego.cz/ a uvidíte:

vytvořeno v 05:29:39, 16.11.04 za 0.00075s | z cache: Ano 

Jinak řečeno, google.com můj web na novém webhostingu opět zaindexoval včera ráno…

Mozilla verze 1.8b2 nativně, a Firefox 1.0 s podporou URIid extension, podporují automatické unikátní id v body tagu a na něj navázané user stylesheets (uživatelské CSS). Opera 7.60 (a nižší verze) je podporuje již dávno, více než 5 let, od verze 4.0 (!).

K čemu je dobrá unikátní identifikace webu?

K čemu to je dobré? Profesionální uživatel si potom může přizpůsobit, pomocí speciálního CSS souboru, vzhled webů, které často navštěvuje, a kde mu něco vadí, nebo chce cokoliv pro sebe zlepšit (třeba tmavé pozadí zaměnit za bílé), právě pomocí uživatelského CSS.

Nicméně, problém je v tom, že uživatelské CSS je v Opeře, Firefoxu, i Mozille jen jedno. Nemůžete tedy napsat toto, protože by potom každý web, který navštívíme, měl bílé pozadí:

body {background:white} 

Řešením je přidat body tagu unikátní id identifikátor, který je obrazem URL, s . zaměněnou za -, což právě dělá Mozilla 1.8b2 nativně, v XHTML to tedy pro můj web bude vypadat takto:

Potom již můžete ve Vašem uživatelském CSS, společném pro všechny weby, psát toto, a promítne se to jen na webu mém:

body#hulan-info-blog {background:white}

Mozilla 1.8b2 umí id přidávat, na základě přepínače, do body tagu automaticky, Firefox na základě zmíněné URLid extension. Výborná funkce! Problém je ovšem, že id doplňuje, dle mého názoru, chybně do body, stylovat je totiž možné i html tag!

BLOG:CMS, nejlepší redakční systém, obsahuje plugin NP_Signature, který nedělá nic jiného, než právě do tagu html toto id automaticky přidá (podívejte se do zdrojových kódů tohoto webu). Každá instalace webu na BLOG:CMS je tak profesionálním uživatelem / čtenářem jednoduše přizpůsobitelná.

Gmail, bezkonkurenčně nejlepší freemail, s dokonalou ovladatelností a s kapacitou 1GB (i pro přílohy), zavedl oficiálně podporu pop3. Osobně to nepoužiji, síla Gmailu je právě v jeho webovém rozhraní, ale pár lidem (asi tak 20 miliónům) se to bude určitě hodit.

Konfigurace pop3:

pop.gmail.com
Use SSL: Yes
Port: 995

Konfigurace smtp:

smtp.gmail.com (use authentication)
Use Authentication: Yes
Use STARTTLS: Yes (some clients call this SSL)
Port: 465 or 587

Tedy, on to možná není ani tak problém s PHP, jako takový zajímavý problém (či bug?) skriptu. Podívejte se na tento kód:

$to = 'info@hulan.info';
$subject = 'New password requested';
$message = 'Hello Radek Hulan,'."\n".
	'You have requested to have a new password '."\n".
	'assigned to your account in the '."\n".
	'discussion forum at http://forum.blogcms.com/. '."\n".
	'Your new password is: abcdefgh';
$headers = 'From: BLOG:CMS '."\n".
	'Date: Sat, 13 Nov 2004 12:26:14 +0100'."\n".
	'MIME-Version: 1.0'."\n".
	'Content-transfer-encoding: 8bit'."\n".
	'X-Mailer: PunBB Mailer'."\n".
	'Content-Type: text/plain; charset=utf-8';

A nyní tento email pošleme:

mail($to, $subject, $message, $headers);

Vtip je v tom, že u mě na SUSE 9.1 s PHP 5.0.2 to email posílá, na xhost.cz s PHP 4.3.9 to email, rovněž posílá, ale na www.tojeono.cz s PHP 5.0.2 to email nepošle. Řešil jsem to s Ondřejem Svobodou asi hodinu, než nám to došlo, a přitom je to tak triviální…

A víte proč?

This script was written to overcome validation problems with RSS 0.9/1.0/2.0 and Atom 0.3 feeds which may not contain (X)HTML entities, otherwise widely used. Usage is very simple, function entity_to_decimal_value() will return a Unicode encoded string, with entities it does not recognise replaced for spaces.

There are also other two useful functions, for converting (X)HTML entities back to their original representation (makes < again <), and for Unicode decoding of an URL string.

/* convert HTML entities back */
function unhtmlentities ($string)  {
  $trans_tbl = get_html_translation_table (HTML_ENTITIES);
  $trans_tbl = array_flip ($trans_tbl);
  return strtr ($string, $trans_tbl);
}

/* decodes URL into Unicode string */
function unicode_decode($txt) {
  $txt = ereg_replace('%u0([[:alnum:]]{3})', '&#x\1;',$txt);
  $txt = ereg_replace('%([[:alnum:]]{2})', '&#x\1;',$txt);
  return urldecode($txt);
}

Včera v noci, poté, co jedna milá kamarádka odešla domů k rodičům (musí zítra do školy), jsem se náhodou dostal ve dvě hodiny ráno na web GeSHi. GeSHi je prima věc, barevná. GeSHi umí obarvit automaticky Vaše zdrojáky v actionscript, ada, apache, asm, asp, bash, c, caddcl, cadlisp, cpp, css, delphi, geshi, html4strict, java, javascript, lisp, lua, nsis, oobas, pascal, perl, php-brief, php, python, qbasic, sql, vb, visualfoxpro, xml.

A ona GeSHi nejenom barví, ale rovněž, pokud ji k tomu mírně přinutíte, udělá třeba pro PHP funkce automaticky odkazy na manuál PHP. Dokonalé. Stejně se dá přinutit i k odkazům na HTML či CSS.

Použití je potom triviálně jednoduché, místo <pre> zadáte <pre language>.

Napsal jsem si k tomu samozřejmě plugin pro BLOG:CMS, pod názvem NP_GeSHi, funguje dvěma způsoby, buď při ukládání článku (parse-and-save), nebo online (realtime), používám přitom tu nej-geniálnější funkci PHP, tedy preg_replace_callback.

include('geshi.php');

class NP_Geshi extends NucleusPlugin {

function parseString(&$content) {
  $keys=array('body','more');
  foreach ($keys as $key)
  $content[$key] = 
   preg_replace_callback (
	'/<pre\s(.*?)>(.*?)<\/pre>/si',
	array(&$this,'replaceString'),
	$content[$key] );
}

function replaceString($r){
  global $DIR_PLUGINS;
  $geshi = new GeSHi($r[2],$r[1],$DIR_PLUGINS."geshi/");
  $geshi->enable_classes();
  $geshi->set_header_type(GESHI_HEADER_PRE);
  $geshi->set_overall_class('code');
  $geshi->set_link_target($this->_linktarget);
  return $geshi->parse_code();
}

} // NP_Geshi

Doplňoval jsem včera sub-kategorie do BLOG:CMS, kvůli zpřehlednění větších webů, a narazil jsem na problém, jak řešit reprezentaci a formátování sub-kategorií v XHTML, a zároveň skrývání/odkrývání skupin v JavaScriptu.

Skoro automatické řešení je použít zde tagy ul, li, nicméně, nakonec se mi jako sémanticky správnější zdálo použití dl, dt, dd, navíc obaleno jedním div, kvůli formátování a XHTML validitě (a MSIE).

Tag dl se zde používá jako formátovací "obal" pro CSS pro skupinu, tag dt je název skupiny, a tagy dd jsou sub-kategorie zařazené v dané skupině. Vypadá to celé nějak takto:

 

  
Skupina 2
   
Kategorie 4
   
Kategorie 5
 

Je to řešení sémantické, XHTML validní, jednoduše nastylovatelné, a poskytující prostor i pro JavaScriptové skrývání/odkrývání skupin kategorií, třeba tímto jednoduchým skriptem:

// strom je zobrazen
var categoryhidden = false;
// schovat strom
function categoryfold(){
categoryhidden = true;
 var i=1;
 var ele;
 while (ele=document.getElementById('group'+i++)) 
  ele.style.display='none';
}
// rozbalit strom
function categoryexpand(){
 categoryhidden=false;
 var i=1;
 var ele;
 while (ele=document.getElementById('group'+i++)) 
  ele.style.display='block';
}
// prepnout strom
function categorytoogle(){
 if (categoryhidden)
  categoryexpand();
 else
  categoryfold();
}
// zobrazit jednu kategorii
function categoryswitch(j){
 if (categoryhidden) {
  categoryexpand();
  return;
 }
 var i=1;
 var ele;
 while (ele=document.getElementById('subcat'+i))
  if (i++==j) 
   ele.style.display='block'; 
  else 
   ele.style.display='none';
 categoryhidden=true;
}

Celé to řešení je vtipné v tom, že funguje na libovolné množství kategorií, ve chvíli kdy ele=document.getElementById('group'+i++) vrátí false, je jasné, že se jedná o poslední skupinu kategorií.

Řešení je implementováno v nejnovější verzi BLOG:CMS, jako plugin NP_SubCategories.php.

Je škoda, že zaostalý MSIE nepodporuje v CSS konstrukce následujícího typu, podobné věci by šlo stylovat v CSS mnohem lépe, bez divů, a rovněž zpracovávat bez hromady id identifikátorů pro JavaScript, jen pomocí DOMu…

div#subcat dl dt>a{color: black; display: block;}