Mikroformáty pod Creative Common

Mikrofotmáty jsou super. Ale bohužel sami o sobě neznamenají naprosto nic. Budu se velice těšit na reakci dvou segmentů, které by měly "aktivovat" mikroformáty pro koncové uživatele. Těmi jsou vyhledávače a prohlížeče. Objevilo se spoustu hlasů, kteří říkali že FF3 bude s mikroformáty pracovat, ale FF 3 beta 2, nic nenaznačuje. A o googlu jsem také ještě žádnou informaci nevyčetl.
Každopádně je dobře že se už alespoň nějaké zprávy o Sémantickém webu (Web 3.0) dostávají oficiálně ven.

[1] Jak to vypada, do FF3 se nakonec stihl dostat pouze backend pro mikroformaty (viz http://developer.mozilla.org/en/docs/Using_microformats - zatim jsem to jeste poradne nenastudoval).

To je plus pro tvurce vsech rozsireni Firefoxu, ktere chteji mikroformaty pouzivat. Dosud se mikroformaty nacitaly parsery psanymi v JavaScriptu, coz bylo pomale. S podporou v backendu to bude mnohem rychlejsi.

Minus je, ze je treba nejake rozsireni nainstalovat, aby uzivatel mohl pres GUI s mikroformaty pracovat. Hlavni duvod je asi ten, ze nikdo netusi, jak by melo GUI pro praci s Mikroformaty vypadat a davat nejaky experiment do stabilni verze Firefoxu asi neni moc vhodne.

Takze zatim tu bude jeste nejakou dobu era pouziti pouze skrze rozsireni a hledani rozumne cesty pro GUI. Az se to ustali, do FF se dostane i frontend. Osobne bych sazel na to, ze v dalsi stabilni rade nasledujici po FF3, to uz bude, ale pockejme si.

[2]
Myslim že tady jsi narazil na jednu nejpodstatnejších otázek Mikroformátů. Nikdo neví jak má GUI vypadat. Takže tu máme perfektní věc, všichni to víme, ale nikdo neví jak to použít (nebo spíš ví a nápadů je hodně, ale nikdo zatim nic neudělal). Jen doufám že to nedopadne jako s Webem 2.0, který měl a má obrovský potencionál, ale je naprosto nevyužitý

[3]
Nápad je to určitě šikovný, a určitě si dovedu představit použití na intranetu - čapnu vizitku ze stránky a přetáhnu si ji do mobilu, atd. Vymyslet k tomu GUI, to ještě dá asi hodně práce, ale přijde mi to jako ta správná cesta.

Web 2.0 - já si myslím, že to, co se označuje za web 2.0. je docela úspěšný koncept - v některých případech, existuje pár veleúspěšných webů a existuje i pár užitečných webů, které by se daly jako web 2.0 považovat. Technologie se dostala neskutečně daleko - můj oblíbený příklad meebo.com, případně last.fm, a najdou se i další.

[3]
Nebyl bych tak skeptický. Například existuje rozšíření Operator (https://addons.mozilla.org/cs/firefox/addon/4106), které funguje docela dobře.

Je jen otázka, jestli se prostě neobjeví jiné GUI, které by vyhovovalo jiné skupině uživatelů. Takže krok FF mě příjde jako velmi moudrý, protože nechává prostor pro různá UI a nenutí uživatelům jednu jedinou možnost...

Web 3.0? Že jsem nezaznamenal žádné předchozí stabilní verze... No nic. Přitom by člověk řekl, že falešní sobi netáhnou.

Co se týče mikroformátů, nějak se mi nepozdává určování sémantiky pomocí atributů class. Viz ten lupácký příklad s adresou IInfa. A celé mikroformáty mi vlastně nepřijdou moc užitečné -- mimo nových možností vyhledávačů (ale: vy např. vyhledáte firmu dle adresy? já teda ne).

[4] A proč nečapnout odkaz vedoucí na soubor vCard a nepřesunout ten?

A abyste neřekli, že jen tak kecám, tak nabízím vlastní návrh (jestli to někdo někdy už navrhl, tak holt není můj vlastní).

Namísto celého tyjátru s atributy class v hlavních rolích a plačící sémantikou ve vedlejší roli by se do specifikace HTML (XHTML...) vmísila celá nová značka: <microformat />. Ta by reprezentovala objekt (ano, objekt, podobnou značku již v XHTML máme) reprezentovaný mikroformátem. V praxi:

<h3>freshmouse<h3>
<ul>
<li>el. pošta: <a href="mailto:­...">adresa</a></li>
<li>jabber: <a href="xmpp:..­.">adresa</a></li>
</ul>
<microformat type="vcard" link="http://gnome-cesko.cz/tmp/fres­hmouse.vcard" summary="freš­mauseho vizitka" />
<p>Další text</p>

... což znamená: celá stávající struktura dokumentů by se zachovala, přibyla by jen nová značka <microformat>. Tato značka by uchovávala odkaz na objekt mikroformátu (obecně: jakýkoli objekt dle atributu type). Jak (a jestli) tento objekt zobrazit, by určoval prohlížeč. Např. by se objekt zobrazil jako tlačítko, po kliknutí by zobrazil také obsah objektu (příp. provedla nějaká akce: poslat někomu zprávu atd.; opět dle preferencí prohlížeče). Atd.

Benefity: zachování stávající struktury dokumentů, nenutnost definice nových formátů, zcela bezpracná definice vzhledu jednotlivých mikroformátů (o tom by si rozhodl klient zcela sám, např. by otevřel nové okno, kde by si to sám uspořádal).

[7] Tvoje reseni ma ovsem par zasadnich nevyhod:

* zahodil jsi zpetnou kompatibilitu (prohlizece neznajici novou znacku vcard nenajdou) aneb Don't Break The Web!
* data, ktera patri do stranky a jsou soucasti jejiho obsahu, jsi vyclenil do externiho souboru, z toho vyplyva komplikovane ukladani dokumentu, nutna aktualizace stavajicich vyhledavacu (tim se vracime k te nekompatibilite) atd.

Priznavam se, ze vyhodu nevidim zadnou.

[8]

* Zpětná kompatibilita? (X)HTML se vyvíjelo a značky se přidávaly, pokud vím. Přece nezakonzervujeme (X)HTML...

* Ta data patří do stránky, a taky tam jsou, viz příklad výše. Že je jako bonus odkazován nějaký soubor, je věc druhá. (Nehledě na to, že CSS, JavaScript atd. lze také separovat do jiných souborů. Stejně tak obrázky, videa a multimediální prvky -- ty jsou součástí obsahu bezpochybně.) Ukládání stránek není o nic problematičtější než nyní -- viz vkládané soubory v závorce výše. Vyhledávače se mohou aktualizovat, a potom budou dávat lepší výsledky, a nebo nebudou -- a potom nebudou dávat tak dobré výsledky, nic jiného (je to jako bát se vytvořit nový formát souborů, jelikož by se jeho případné prohlížeče musely aktualizovat).

Jestli má ovšem můj návrh nějakou nevýhodu, je to nutnost protlačování změn přes W3C a podobné oragnizace. Jinak nic.

Ono právě přidávání značek se zpětnou kompatibilitou zpravidla počítalo. Klasické použití fallback content. Počínaje kdysi zavedením obrázků a skriptů a konče dnes třeba celými webforms2.

[11] Dobře, potom lze ovšem místo <microformat ...> použít třeba <span>. V každém případě lepší než to stávající mikroformátové řešení (subjektivně).

Jenze prejmenovat znacku nepomuze tomu, ze se odkazovany soubor obsahujici cast obsahu stranky proste nenajde 8-)

[13] Ale o tom je zpětná kompatibilita. ;-) Pokud je klient kompatibilní, nabídne namísto <span type="vcard" ...> nějaký prvek stránky, a pokud ne, nestane se nic. Nehledě na to znova upozorňuji: obsah toho objektu je na stránce stejně k dispozici prostřednictvím značek jako <h*>, <p> atd. (opět odkazuji na příklad v [7]).

Aha, ted uz rozumim. Ty proste nabizis obsah dvakrat vedle sebe. Jen jej pokazde proste nabidnes v jinem zapisu. Tak v tom pripade tu ale mam dalsi nevyhodu 8-)

Ne vazne, ja na tomhle nevidim nic zazracneho. Na Mikroformatech se mi prave libi myslenka "vse v jednom", zadne duplikovani obsahu.

Přesně tak, dva v jednom.

Duplicita nevadí, je jen zdánlivá. Zaprvé je obsah většinou generován automaticky, takže nehrozí, že to chudák nějaká bába bude datlovat dvakrát. Zadruhé, vyhledávače se velmi rychle přizpůsobí (zvláštní, jak jsem změnil gramatický čas :-]) a nebudou jeden obsah nabízet dvakrát. Takže žádný problém, bez starosti. :-)

A hlavní výhodou mého návrhu je, že tvůrce webu se nemusí (a ani nemůže) starat o zobrazení nějakého mikroformátu, jelikož obsah přímo zakomponovaný do stránky (jako <h*>, <p> atd.) se zobrazí "standardně", a o (případné) vykreslení objektu se postará klient (zobrazí tlačítko, zobrazí obdélníček... cokoli). V tom vidím tu největší krásu (mimo absence <span class="">ových orgií).

proboha, k cemu tento bastl mikroformatu, kdyz existuji nazvove prostory a odkaz na dtd. o naruseni nazvoveho prostoru doposud vyhrazeneho pro css ani nemluve.
Kdyz uz tedy ma nekdo potrebu znovy vymyslet kolo, tak at to alespon dela poradne(byt je ta cinnost zbytecna).

[17] Mily anonyme, na jmenne prostory se tady bohuzel spolehnout nejde, protoze reseni musi byt funkcni v celem prostoru (X)HTML. Attack na jmenny prostor CSS ze strany mikroformatu je skutecne jednou z jejich slabin, ale verim ze prekonatelnou.

[16] Ja ti dam zdanliva 8-) Mikroformaty nejsou jen pro stranky firem s par adresama, vem si treba mapy (tusim zatim jen Google, Yahoo µF pouzivaji) a predstav si, ze pro kazde zobrazeni adresy na mape by se krome AJAXoveho stazeni dat navic (a to podotykam zbytecne) musel volal dalsi request pro externi soubor s vcardem (a to muzou byt desitky adres na jednu stranku, vem si kolik mas pozadavku navic), nehlede na zbytecnost tvorby URL, ktera by tyhle vcard soubory generovala. Podobne sluzby typu linkedin nebo zlatestranky, zobrazujici pod sebou desitky kontakty a najdeme dalsi a dalsi a bude to jen horsi a horsi 8-)

Tve reseni je urcite zajimave z pohledu minimalnich zasahu do soucasnych zvyku prace s HTML, o tom nepochybuji, ale pro realne nasazeni je ryze neprakticke.

[19] Ale vždyť není třeba nic stahovat vícekrát! Ten externí soubor se přece nemusí stahovat vždy. Stáhne se jen kód, který ho deklaruje (<microformat type="" link="" summary="" />), a to i při hodně, hodně velkém adresáři dělá tak kilobajt nebo dva.

A vzhledem k tomu, že je např. ta vizita zobrazena i prostřednictvím <h*>, <p> atd., nebude takový zájem stahovat ještě ten soubor s mikroformátem. Většině lidí by stačilo např. tlačítko "Vizitka", s kterým by naložili podle sebe (přetáhli do adresáře atd.).

Tvorba URL je to nejmenší, viz YouTube. :-D

A i kdyby si někdo chtěl postahovat např. všechny vizitky ze stránky (prohlížeče by to určitě časem uměly), nebyl by nápor na servery zas takový. Když dám vyhledat obrázek na Google, standardně vyjede 18 obrázků, což je daleko horší.

Já vidím využití mikroformátů i (nebo spíš?) mimo web. Nějaký poskytovatel obsahu bude dodávat data ve zformátované podobě (třeba článek s údaji o autorovi, v něm geografické lokace, odkazy na jiné publikace apod.) a klient, který tento formát přijme jej využije k provázání s dalším obsahem - např. vyhledá lokace v mapách (Google Earth, ...).

Ten klient samozřejmě může být "obyčejný" prohlížeč, ale ten nikdy nebude umět všechno. (Je možné do něj "teoreticky" nacpat doplňky rozumějící všem možným mikroformátům, ale asi si každý dovede představit, co to udělá s jeho výkonností a stabilitou).

Specializovaný klient (třeba mapový program ala Google Earth) ale bude moci pracovat se _stejným_ kusem dat jako jiní (či spíše konzumenti těchto dat), např. nějaký knihovník.

Důraz kladu na ten _stejný kus_ dat. Skutečná data, ne odkaz na ně, a v jednom kuse.

[21) "stejny kus" - ano, to je to reseni "vse v jednom", ktere si na µF tak pochvaluji.