Monthly Archives: november 2009

Demo 2009 – ott leszünk

6 Replies

Az imént jött a levél, hogy a “Social Media Campaign Center” munkanevű startup ötletünkkel bejutottunk a (hazai) Demo ’09 döntőjébe, avagy a decemberben rendezendő konferenciára. 30 pályázó közül először 15-öt, majd végül 8-at választott ki egy számomra nagyon szimpatikus, igazi szakmai megbeszélésen a zsűri (mely befektetőkből, a piacot és a különböző technológiát is jó ismerő szakemberekből állt).

demo09

Az Amerikából indult DEMO már húsz éve ad lehetőséget a startupok számára megmérettetésre, s hasonlóan működik, ahogy az általam is szervezett Startup konferencia: az előadók 6 percben mutathatják be projektüket a közönség előtt. Hazánkban eddig még csak egy alkalommal került megrendezésre, tavaly én teljesen lemaradtam róla.

Ötletünk az olyan közösségi média kampányok hatékony, gazdaságos kivitelezését elősegítő eszköz, melyről a későbbiekben majd még osztok meg részleteket. A konferencián első helyezést elérő startup lehetőséget kap a jövő év elején szervezendő amerikai konferencián való részvételre is. Tekintettel arra, hogy a mi ötletünk sokkal hasznosabb, mint amilyen látványos, ezért komolyabb eredményeket egyelőre nem várok a részvételtől, de majd még meglátjuk, hogy hogyan sikerül majd a prezentáció.

Where Is the Love?

6 Replies

Mostanában elég sok olyan nyílt forrású projektet nézek meg (tegye fel a kezét, aki nem nyílt forrású cuccokat használ fejlesztéseihez manapság), melyek frissnek, újnak számítanak. Keresem az új ötleteket, vagy a régi ötletek jól használható megvalósításait. Egyre könnyebb megtalálni ezeket a projekteket.

code-guru

Két fajta forrásom van, az egyik típus a nyílt forrású kódokat hosztingoló oldalak, a másik típus pedig a blogok, melyek kedvenc témáimról szólnak. Ezzel alapvetően gondolom nem mondtam újdonságot, de ezeket most megpróbálom össze is gyűjteni, hátha tudok adni olyan tippeket, melyeket mások nem ismernek. Szívesen venném azt is, ha ti is megosztanátok kedvenc forrásaitokat.

Forráskód hoszting oldalak

Szóval jellemzően két forráskód hoszting oldalt ismerek, ahol rengeteg új projekt talál otthonra. Mind a kettőnél díjmentesen hosztolhatjuk nyílt forrású kódjainkat, ha ilyen projektbe kezdünk, mindenképp megéri valamelyik közül választani:

GitHub

A Git verziókezelő rendszer egyre nagyobb teret hódít, s bár én még nem próbáltam ki, de valamikor annak is eljön majd az ideje. E köré lett felépítve a GitHub, mely a publikus projekteken kívül arra is lehetőségek kínál, hogy saját projektjeinken dolgozzunk. Keresőjével elég sok érdekességet lehet fellelni. Itt van hosztolva a Node.js és a Redis, de itt található meg a Cappuccino, a Processing JS, az Underscore, az NGiNX HTTP push module és még több tucatnyi érdekes kód.

A Git lehetőségeiből adódóan bárki nagyon könnyen hozzá tud járulni ezeknek a projekteknek a fejlődéséhez, mivel nem kell hozzáférést kérni a forrás írásához, hanem könnyen lehet új ágat indítva belefejleszteni amit szeretnénk bármely projektbe, aztán persze a kód tulajdonosa majd eldönti, hogy ez bekerüljön-e a fő ágba.

Google Code

A Google Code egy SVN alapú kód hoszting szolgáltatás, mely nem csak a kódok tárolását, hanem komplexebb lehetőségként azok wiki alapú dokumentálását, illetve hibajegy kezelését is lehetővé teszi. Itt vannak közzétéve a Google saját nyílt forrású kódjai is (az Androidtól kezdve a Closure-ig). Sajnos a keresője (pedig Google!) messze nem olyan jó, mint a GitHubé, de azért érdekes projekteket lehet itt is fellelni. A Redis például itt kezdte a kódjának a közzétételét, majd átköltözött a GitHubra, de a dokumentáció és hibajegy kezelés az itt maradt. Itt van az openscope, swfobject, a PubSubHubBub, a flot, az iui, a blueprintcss, a TrimPath, stb.

Blogok

A blogok hagyományosan olyan információforrások, melyek jól válogatott, érdekes tartalmakat kínálnak. Én a következőkre vagyok feliratkozva:

Egyebek?

Ami még jól használható, de jó zajos forrás is egyben, az a delicious megfelelő feedjei, de a popular részlegre is feliratkozhatunk. Ti mit olvastok, követtek a webfejlesztés tág témakörét illetően?

Mac OS X + Flash 10.1: videó problémák

3 Replies

Az újdonság varázsa elbűvölt, és úgy döntöttem, hogy feltelepítem a Flash 10.1-es verzióját, hogy kipróbáljam tényleg olyan gyors-e ahogyan olvasni róla. Erről meggyőződni végülis nem tudtam, ámde az összes videó lejátszás elromlott a YouTube-tól az IndaFilmig, a régi Flash verziót pedig nem engedte telepíteni a rendszer. Pár nap után elegem lett a dologból, és rászántam magam hogy megkeresem a megoldást – ami hasznos lehet azoknak is, akik Flashre fejlesztenek, és váltogatni szeretnének különböző verziók között Macen.

mac-os-x-flash-problem

Röviden a megoldás: a /Library/Receipts/Adobe Flash Player.pkg törlése. Próbáltam leszedni a Flash-t, ami sikerült is (bár az uninstaller elég sokat gondolkodik cselekvés előtt), de ez sem hozott megoldást: a rendszer továbbra sem engedte a régebbi verzió (10.0.x) telepítését, egy “A newer version of this software already exists on this volume.” hibaüzenettel szerelt le. A bekezdés elején említett fájl törlésével a telepítő végül már nem reklamált, s engedte telepíteni a korábbi változatot is.

Egyébként ahogy kiderült, a /Library/Receipts/ könyvtárba a telepítők dolgoznak, ide rögzítenek különböző jogosultságokat leíró információkat a telepített alkalmazásokról. Az itt levő fájlok eltávolítása akkor okozhat problémát, ha egy már telepített alkalmazást meg szeretnénk gyógyítani, ez esetünkben nem igazán állt fenn, nálam már fenn se volt a Flash, tehát nyugodt szívvel törölhettem a hozzá tartozó fájlt. Hasonló probléma egyébként más programoknál is előfordulhat, a megoldás keresgélése közben én végülis egy MySQL telepítés kapcsán fellépő probléma leírásánál találtam meg a megoldást.

A történet egyébként segített ráébreszteni arra, hogy mennyire függök – és valószínűleg függünk – a Flashtől és a videózástól, érdekes élmény volt.

Google Chrome OS

18 Replies

Ma este demózta a Google a Chrome OS-ét, vagyis az operációs rendszerét, melyre nagyon régóta vártunk már. Linux alapú, nyílt forrású (már el is érhető valami), a Chrome böngészőre épülő megoldásról van szó, melyen webalkalmazások futnak. Engem nem győzött meg az egyébként oldszkúl sajtótájékoztató, s bár nem rossz amit összeraktak, de egyszerűen nincs miért használnom.

chrome-osFotó: Engadget

Sokat lehetne írni a sajtótájékoztatóról, ahelyett hogy szép kerek mondatokat fogalmaznék meg, inkább megpróbáltam gondolatokat összegyűjteni a témában. Lássuk:

  • Az otthoni gépeden, eddigi hardvereken nem fog futni, a Google felügyeli majd azt, hogy mivel adják el (minőségi alkatrészek, megfelelő felbontás, csak SSD, modern netkapcsolat). Tanultak vajon az Androidból? Hogyan fogják ezt csinálni, ha nyílt forrású lesz a rendszer? Állítólag már ma fut emulátorban a cucc, nem értem miért nem fogják ügyes hackerek gyorsan összedobni belőle a letölthető változatot holnapra.
  • Nincs killer alkalmazás. Minden amit láttunk, megy egy sima böngészőben is. Egyedül a panelt hozták fel példaként (taszkbarra lerakott webalkalmazások kb.), meg talán még az oprendszer védettsége ami viszonylag egyedinek mondható. Miért fogját az emberek ezt választani egy mai rendszer helyett?
  • Riporteri kérdésre válaszolva, miszerint van-e célár, lesz-e a Google-nek ilyen megkötése a hardvergyártók felé, azt a választ kaptuk, hogy nem, nem lesz ilyen. Pedig lehetne, szerintem a Chrome OS csak és kizárólag az árral adható el ugyanis.
  • Flasht fognak használni. A videók lejátszásához, videók készítéséhez (kamera és mikrofon kezelése) nem is nagyon tudnak mást. Riporteri kérdésre, miszerint mi van a Silverlighttal, határozott nem nyilatkozom választ adtak.
  • Egyéb böngészők nem fognak futni a Chrome OS-en. Mert a futtató környezet maga a Chrome. Ha más böngésző gyártók labdába akarnak rúgni, akkor ott a nyílt forráskód, és csináljanak ők is hasonlót.
  • Második számítógépnek tervezik csak egyelőre, határozottan nem az OS-en futni minden. Riporter a Photoshopra is rákérdezett, megkapta hogy az Adobe megcsinálhatja a weben, nagyon várják. “Ha ügyvéd vagy, és egész nap szerződéseket szerkesztesz, akkor ez nem neked való.” – elég hülye a példa, szerintük erre nem jó a Google Docs?
  • Minden adat a felhőben van, a notepad alkalmazás is a Google Docs-ba ment.
  • Az Excel fájlokat a Windows Live-val nyitja meg az oprendszer.
  • A biztonságról sokat beszéltek, automatikus frissítés, aláírt kódok, önmagát ellenőrző, támadást kijavító oprendszer. Ebben én nem látok versenyelőnyt, bármelyik netbookon ha csak böngészőt használok, többnyire nem vagyok veszélyben.
  • Csak jövőre (vagy később) várhatjuk az első kiadást.
  • Sergey Brin beugrott, mondott pár hülyeséget, aztán elment.
  • Csak SSD lesz a gépben, az oprendszer nem írható lemezen lesz. ARM gépen működik jelenleg a rendszer.
  • Dual boot nem lesz.
  • A Google már kiadta az Androidot mobiltelefonokra. Úgy tűnik semmi átfedés nem lesz a kettő között, Andorid alkalmazásokat nem lehet majd futtatni a Chrome OS-en.
  • Lesz valami Application Store szerű (miért ne lett volna), bár alapvetően webes alkalmazásokról van szó, összegyűjtik azokat majd egy helyre, hogy az emberek megtalálhassák őket. Többé-kevésbé bárki tud majd ilyen weboldalt csinálni ha jól gondolom, egyszerűen semmi olyan nem hangzott el, amivel meg tudnák fogni a felhasználókat és magukhoz kötni. Az alkalmazás egy URL beütése a böngészőbe.
  • Eee PC-n demózták a bootolást, 7 másodperc.

Nos, ennyit az első benyomásokról. Vannak jó ötletek, de a fentieket többnyire bármelyik netbook OS-nek szánt Linux disztribúció hozza, nem győztek meg arról, hogy erre várnom kéne. Részemről maradok az igazi számítógépeknél és oprendszereknél, ez csak valami buta utánzat.

Acquia Drupal telepítő

2 Replies

Ezen a hétvégén zajlik hazánkban a Drupal Hétvége, s bár részt venni rajta nem tudok, de péntek-szombat-vasárnap Drupalos pólóimmal tisztelgek az esemény előtt, illetve próbálom követni a fejleményeket. A tegnapi előadások fóliái, sőt, a videók is már elérhetőek a rendezvény honlapján. Bár már korábban is hallottam róla, most sikerült eljutnom odáig, hogy kipróbáljam a helyi gépre egy komplett Drupalt varázsló kezdeményezést, az Acquia Stack Installert, amit ezúton ajánlanék.

drupalcontrolpanel

Az Acquia Stack Installer a Drupal alapjait lerakó, illetve a közösséget továbbra is aktívan vezető/támogató Dries Buytaert cégének, az Acquianak a fejlesztése. Egy Apache+PHP+MySQL, illetve Drupal telepítőről van szó, mely nem csak feltelepíti ezeket a szoftvereket a szükséges beállításokkal, de a menedzselésüket is lehetővé teszi.

A Windowsra és Mac OS X-re is elérhető telepítő nem csak az alap Drupalt, hanem még egy adag modult is feltelepít, a célja az, hogy nagyon gyorsan egy működő Drupal környezet álljon a rendelkezésünkre, melyet mind felhasználóként, mind pedig fejlesztőként birtokunkba vehetünk. A telepítés nálam zökkenőmentesen lezajlott, s letöltéssel együtt röpke tíz perc alatt már el is kezdhettem kattintgatni a Drupal oldalon.

A Drupal mögött nem csak nemzetközi szinten, de hazánkban is egyre nagyobb fejlesztői kapacitás sorakozik fel, s a Drupal.hu mögött álló csapat is szép munkát végez a népszerűsítést illetően. A Drupal felhasználói interfésze, s az elérhető lehetőségek a kemény munkának köszönhetően egyre jobbak lesznek, a 7-es Drupal verzióban kellemes újdonságok várhatóak.

A HTML 5 és CSS 3 újdonságai

14 Replies

Beindult a marketing gépezet a HTML 5 kapcsán, viszont viszonylag keveset hallani arról, hogy a marketing dumákon kívül miről is van szó pontosan (bár korábban például már én is írtam a HTML 5-ről). A Flash leváltására alkalmas csodaszerként, a Google új fegyvereként, a HTML webkettőjeként szokás emlegetni, holott a történet egész másról szól. Egy néhol száraz, de igen érdekes specifikációról. Sőt, a HTML 5 mellett itt van a CSS 3, és itt van az SVG és egyéb más lehetőségek is. Egy több bejegyzésből álló sorozatban megpróbálom összeszedni, hogy mi is volt a HTML 5 és a CSS 3 története, hogy pontosan milyen új eszközöket kapunk ezekkel a specifikációkkal, s hogy hol tart most ezeknek a böngészőkben implementálása.

html-5-fifth-element

HTML 5 – így történt

A Wikipédia HTML 5 szócikke nem túl bőbeszédűen, de egész jól összeszedi, hogy hogyan is jutottuk el a HTML 5 mai állapotáig. Az egész a WHAT Munkacsoport (Web Hypertext Applications Technology Working Group) megalakulásával kezdődött 2004 júniusában, pár hónapos előkészítő munka után. A csoport alapítói az alternatív (IE-hez képest) böngészőgyártók, konkrétan az Apple (Safari), a Mozilla Alapítvány (Firefox) és az Opera Software (Opera) voltak, céljuk egy a W3C-tól független, annál hatékonyabban működő, nyitott, laza összefogás volt. A Microsoft eleinte ki lett hagyva a játékból, később pedig egy ideig még nem ismerte el a törekvéseket, de az IE 8 kapcsán már elkezdett implementálni részleteket, és az IE 9-ben további implementációk várhatóak. A W3C akkoriban nem a rugalmasságáról volt híres, a (nem alacsony tagdíjat fizető) tagok vehettek csak részt a döntésekben és az irányok meghatározásában, és sokkal inkább az akadémiai hozzáálláson, mint a praktikumon volt a hangsúly. A problémák a W3C ajánlásokban szereplő, de a böngészőkben nehezen megvalósítható, vagy egyszerűen csak nem használt funkciókban (lásd például a CSS 2.1 megjelenésének oka, vagy az XHTML 2.0 teljes csődje) jelentkeztek.

A WHATWG a Web Forms 2.0, Web Apps 1.0 és Web Controls 1.0 dokumentumok elkészítésével kezdett el foglalkozni. A Web Forms célja a HTML 4.01-ben definiált form elemek olyan jellegű bővítése volt, melyek a régi böngészőkkel is kompatibilisek, de igazodnak a kor igényeihez, és JavaScripttel a régi böngészőkben is megvalósíthatóak. A Web Apps egy sokkal összetettebb, a webalkalmazásokat támogató, már létező és teljesen új fejlesztések szabványos irányba tereléséről szólt. Új HTML elemektől kezdve a session kezelés, a helyi adattárolás, WYSIWYG szerkesztés, 2D és 3D canvas, különböző kommunikációs megoldások és további kisebb-nagyobb fejlesztések mind a HTML leíró nyelvet, mind pedig a DOM-ot illetően az, amit magába foglalt a specifikáció. Végül a  Web Controls célja olyan lehetőségek definiálása volt, melyek lehetővé tennék új “widgetek”, kvázi HTML elemek definiálását és működésének leírását.

Az új ajánlások közzététele és tervezése eleve a W3C ajánlások formátumával kompatibilis módon zajlott, és célként volt kitűzve, hogy amennyiben lehetséges, a W3C fogadja majd be a dokumentumokat. A szabványok kialakítása ezután nagy lendülettel elkezdődött, új elemek is beléptek, és volt olyan is, amiről kiderült, hogy mégsincs rá szükség, és 2006-ban indult egy blog is, mely folyamatosan beszámol azóta is a fejleményekről. 2007-ben a W3c bejelentette, hogy újra nekifut a HTML történetnek, ekkor már nyílt levelezőlistával, és határozottan együttműködve a WHATWG-vel is.

A Web Apps 1.0-ba végül beleolvadt a Web Forms 2.0, és átnevezték HTML 5-re, a Web Controls pedig időközben elhalt a nem túl nagy érdeklődés, illetve a hasonló célú XBL 2.0 miatt.

HTML 5 – itt tartunk

A HTML 5 fejlesztése kifejezetten aktív. A specifikálás azóta sem állt meg, s bár elég jól körvonalazódott már a HTML 5 tartalma, továbbra is előfordulhat, hogy új elemek kerülnek be, vagy kikerülnek kevésbé fontos elemek, sok részlet pedig folyamatosan finomításra kerül. A böngészőgyártók elkezdeték implementálni a különböző lehetőségeket, összességében elmondható, hogy az összes szóba jövő böngésző jó úton halad, s még ha az Internet Explorer le is van maradva, de a legtöbb dolog ebben a böngészőben is implementálva lesz szépen lassan.

Egy bekezdésben nehéz lenne összefoglalnom, hogy mennyi részlete van a specifikációnak, nagyon-nagyon komplex. Nagyon sokat lehet tanulni belőle nem csak a jövőről, de arról is, hogy most hogyan működnek a böngészők és úgy általában a web, hiszen a céljai között az eddig nem dokumentált, de az évek során kompromisszumos megoldásként összeállt viselkedések definiálása is szerepel. A dokumentum nem csak a HTML elemeket, hanem a DOM lehetőségeit, illetve egyéb, a HTML feldolgozásához, megjelenítéséhez kapcsolatos részleteket is leír. Íme egy önhatalmúlag összeállított kivonat:

  • oldalvázat, szekciókat leíró elemek: body, section, nav, article, aside, h1-h6, hgroup, header, footer, address
  • új szöveges elemek, mint például: time, progress, meter
  • új tartalmat beágyazó elemek, mint például: figure, video, audio, source, canvas, map
  • az újfajta beviteli mezők, form elemek és a komplex formok leírását lehetővé tevő jelölők, elemek
  • interaktívitást lehetővé tevő elemek: details, command, menu
  • microdata – adatok HTML-be ágyazásának és kiolvasásának módja
  • a HTML és a JavaScript kapcsolatát, események működése
  • offline alkalmazások létrehozásának lehetősége
  • linkek, kapcsolódó tartalmak leírásának (feedektől a nofollow-on át a faviconokig) módja
  • a felhasználói interakcióval kapcsolatos lehetőségeket, mint például: szöveg kiválasztása, WYSIWYG szerkesztés lehetősége, helyesírás ellenőrzés, drag’n'drop
  • kommunikáció különböző domainek között az oldalon belül és a külvilággal
  • HTML vs. XHTML kérdést és a feldolgozás mikéntje
  • a megjelenítés az alapvető kérdésektől a betűtípusok kezeléséig
  • az idejétmúlt elemeket mint például: applet, marquee, frame, DOM lehetőségeket és az ezekkel kapcsolatos hibakezelést

Elég szabadon válogattam a dokumentumból részleteket, de a lista hosszúságából talán látszik, hogy nem egy 5 perces olvasmányról van szó, s hogy a böngészőgyártók elé igen komoly feladatok vannak kitűzve. Hogy tovább árnyaljam a képet, az olyan lehetőségek például, mint a canvas elem, itt a felsorolás egyik pontjában egy belső felsorolás részeként szerepelnek csak, holott egy könyv teljes fejezetét, vagy akár egy könyvet is lehetne szentelni a témának.

CSS 3 – így történt

A CSS 3 egy egészen más utat járt be, a kezdetektől W3C projektként fut. Itt is érdemes elolvasni a Wikipedia CSS bejegyzését, jól mutatja be a CSS múltját. A CSS 2 1998 májusában jelent meg, de a böngészők már ekkor komoly lemaradásban voltak, a Macintoshra kiadott Internet Explorer 5.0 a CSS első változatát is csak két évvel a második változat kiadása után, 2000-ben implementálta, és ezzel az első, legmodernebb böngésző volt akkor. A második változatot évekkel később sem tudta egyik böngésző sem megvalósítani teljes egészében annak viszonylagos összetettsége miatt. A helyzet normalizálása érdekében hozta ki a W3C a CSS 2.1-es változatát, mely alapvetően egy butított megvalósítás volt, a praktikumot előtérbe helyezve, és igazodva az akkori böngészőkhöz kihagyták belőle a “megvalósíthatatlan” részeket.

Tanulva a hibáiból a CSS 3 immár modularizált lett, vagyis különböző funkciók mentén modulokra robbantották az újdonságokat, melyeket a böngészők így “csomagban” tudnak megvalósítani, vagy akár átmenetileg figyelmen kívül hagyni. A CSS 3 egyes moduljai közel végleges, más moduljai kezdetleges állapotban vannak (helyzet), hatalmas mozgolódás nincs is ezirányban a specifikáció terén (a teljesen hiányos roadmap), havonta egy-két dokumentum frissül. Az implementációt illetően a böngészőgyártók bár nem rohannak, de jó ütemben implementálják az érdekesebb modulokat, adott funkciókat egész jól valósítanak már meg, sok dolog van még így is hátra.

A CSS 3 fejlesztése is sokkal nyitottabb folyamat már, mint korábban volt, a levelezőlistához bárki csatlakozhat, és véleményt, javaslatokat formálhat az irányokról, problémákról.

CSS 3 – itt tartunk

A CSS 3-nak vannak izgalmas, már-már eszement részei is, érdemes átfutni a specifikációt, és ismerkedni egy kicsit a várható irányokról, de ezeket én is igyekszem majd összefoglalni. Ahogy a HTML 5-nél, itt is összeszedtem egy listát, mely a CSS 3 különböző moduljait, és azok szerepét foglalja össze:

  • CSS Template Layout: a CSS 2.1-ben “nincs” olyan elem, mely oldalak layoutjának leírására, meghatározására szolgálnak (a float-ok ilyen célú használata például egy kompromisszum csak), a CSS Template Layout ezt a hiányosságot próbálja meg orvosolni. Elsőre elég vad és szokatlan, de mégis hatékonynak tűnő leíró megoldással.
  • CSS Aural Style Sheets: a CSS alapvetően a vizuális megjelenítésről szól, ez a CSS 3 modul viszont azt írja le, hogy hogyan lehet hangokat kapcsolni a dokumentumokhoz, illetve az eseményeihez (hover, oldal betöltődés, stb.), továbbá hogy hogyan lehet ezeknek a hangoknak a különböző tulajdonságait befolyásolni (balansz, hangerő, stb.).
  • CSS Backgrounds and Borders: a CSS 2.1 szabvány viszonylag puritán lehetőségeket kínál egy adott block megjelenésű elem hátterének és keretének beállításához. Ez a modul azt írja le, hogy hogyan rendelhetünk akár több háttérképet is egy elemhez, hogy hogyan állíthatjuk be azok pozícióját, kivágását és torzítását, illetve a kereteket illetően hogyan lehet a vonalak helyett képeket használni, vonalas keretet hogyan lehet lekerekíteni, s hogyan lehet árnyékot beállítani.
  • CSS Basic User Interface: formok különböző állapotaival kapcsolatos kiválasztók (Web Forms 2.0-hoz kapcsolódóan), a kerethez hasonló outline, egérkurzorok – az alapvető felhasználói interfész elemekről szól ez a modul.
  • CSS Basic Box Model: szintén alapvető dolgokkal foglalkozó modul, mely a doboz modellről szól, a display tulajdonság különböző értékeiről, a float és clear hatásáról és viselkedéséről, az overflow-ról és hasonló témákról. Az eddig használt, de részleteiben nem definiált, az IE overflow-x, overflow-y lehetőségének “legalizálásáról” és teljesen új dolgokkal is foglalkozik ez a modul.
  • CSS Extended Box Model: ami nem fért bele a  Basic modellbe – egyelőre ebben a modulnak még nem kezdődött el a publikus kidolgozása sem
  • CSS Marquee: animált üzenősáv lehetőségek leírását teszi lehetővé, a doboz modell moduljából vált ki.
  • CSS Cascading and Inheritance: ez a modul az olyan alapvető szabályokról, mint az öröklődés, egymásba ágyazás, különböző médiák kezelése szól, alapértelmezett értékek, szabályok súlyának számítása szól. Alapvetően az eddig nem tisztázott, de nagyjából ugyanúgy működő megoldások pontos dokumentálása a célja, nagy újdonságokat nem hoz be.
  • CSS Color: a színek leírásának módjáról szól, ami újdonság benne, az legfőképpen a “negyedik dimenzió”, avagy a áttetszőség mint “szín” komponens kezelése.
  • CSS Fonts: a betűkészletek kezelését foglalja magában ez a modul, újdonságot a betűtípusok méreteinek egymáshoz igazításával és a “letölthető”, avagy a felhasználó gépén nem jelen levő betűkészletek használhatóságával kapcsolatban hoz.
  • CSS Generated Content for Paged Media: a Paged Media modulon felüli lehetőségek “oldal alapú” médiákhoz, mint például egy nyomtatott dokumentum verzió, vagy akár egy prezentáció. Olyanok vannak benne, mint dinamikus hivatkozások a dokumentumon belül (“lásd a 25. oldalon”), vagy például az oldal fejlécének/láblécének beállítása a dokumentum h1/h2/h3 (vagy bármilyen más) elemeinek segítségével.
  • CSS Generated and Replaced Content: oldal tartalmak létrehozásáról, vagy cseréjéről szóló modul, “hivatalosan” ezzel lehet például egy szöveges fejléc elemet képre cserélni, vagy adott elemek elé/mögé beszúrni tartalmakat
  • CSS Hyperlink Presentation: a linkek megjelenéséért, viselkedéséért felelős, például hogy mikor számít “aktívnak” egy link, de az is leírható a modulban foglaltak segítségével, hogy hol (új ablak, fül, stb.) nyiljon meg egy link.
  • CSS Introduction: ez egy összefoglaló modul, ami egy bevezetést, áttekintést (fog) adni a CSS 3 lehetőségeiről – majd ha “kész” lesz.
  • CSS Line Layout: a sorok függőleges igazítását, továbbá az összefüggő szövegek első karakterének, első sorának kiválasztóját írja le.
  • CSS Lists: a különböző listák megjelenésének leirhatóságát szabályozza ez a modul, a számozástól kezdve képek elhelyezéséig a listaelemek elé.
  • CSS Math: matematikai képletek, kifejezések (MathML) megjelenésének szabályozását végzi.
  • CSS Multi-column Layout: szövegek több oszlopba renderelését megvalósító modul, az oszlopok számának megadásától az elválasztó “hézag” paraméterének megadásáig lehet szabályozni a megjelenítést.
  • CSS Namespaces: az XML névtereinek támogatása CSS-ben is: a kiválasztók kiegészítése névtér támogatással.
  • CSS Object Model: a DOM “szabvány” azt szabályozza, hogy hogyan érhetőek el és módosíthatóak a HTML és XML dokumentumok “kívülről” valamilyen (pl. JavaScript) programnyelv által, ez a modul ugyanezt írja le, csak a CSS tulajdonságok kapcsán.
  • CSSOM View Module: egy dokumentum megjelenésének szabályozása valamilyen (pl. JavaScript) programnyelv által – konkrétan a dokumentum és elemek scroll pozíciójának állítása került bele ebbe a modulba, de foglalkozik a tartalmak kiválasztásával és az egér eseményekkel is.
  • CSS Paged Media: a korábban már említett modul, mely az oldalak fejlécének, láblécének, oldalak sorszámozásának állításáért felelős.
  • CSS Positioning: a position tulajdonság értékeinek pontos viselkedését szabályozó modul.
  • CSS Presentation Levels: különböző megjelenési szinteket, lépéseket definiál, például egy prezentáció egyes oldalaihoz definiálhatunk lépéseket (hányadik lépés), és megadhatjuk, hogy ha az adott lépésnél (szintnél) vagyunk, akkor mi legyen látható.
  • CSS Reader Media Type: ez a modul már megszűnt, de a különböző felolvasók támogatásáról szólt.
  • CSS Ruby: egyes írásoknál (pl. kínai és japán) léteznek az olvasást segítő “meta” írásjelek, melyek például az adott “szó” kiejtését teszik egyértelművé – ezek az úgynevezett “ruby”-k. Ezek pozícionálását szabályozza le ez a modul.
  • CSS Scoping: hogy pontosan mi is akarna lenni ez a modul, arról nem találtam konkrét információt, de a CSS Namespaces modulban létezik egy hasonló témakör – mely a kiválasztók működési területéről szól.
  • Grid Positioning: a CSS Template Layout modul is megpróbál választ adni arra a kérdésre, hogy hogyan lehet leírni egy komplex oldal layoutját, ez a modul is ezért a területért felelős, s alapvetően “grid”, azaz háló alapú layoutok leírását teszi lehetővé, kevésbé vad szintakszissal, mint társa.
  • CSS Speech: ez a modul azt szabályozza, hogy egy adott dokumentum hogyan prezentálható hang formában. Elég sok felhasználási lehetősége lehet az okostelefonoktól a navigációs rendszerekig.
  • CSS Style Attribute Syntax: a HTML (és egyéb CSS-sel szabályozott dokumentumok) “style” tulajdonságának formátumát definiálja – ez az egyik olyan alapvető dolog, ami korábban nem igazán volt szabályozva.
  • CSS Syntax: a CSS szabvány formátumának átfogó szabályozása, a leírónyelv filozófiáját foglalja magában.
  • CSS Tables Module: a táblázatok megjelenéséért felelős modul.
  • CSS Text: szövegek megjelenését szabályzó modul, az aláhúzástól kezdve a szövegek több sorra törésének leírásáig foglalja össze a terület kérdéseit.
  • CSS Text Layout: folytatja az előző modul feladatait, a függőleges írásiránytól kezdve a jobbról-balra történő írások jelöléséig.
  • CSS Line Grid: összetett szimbólumok vonalhoz igazodását leíró modul, mint például a japán szövegek karaktereinek egymás alá illesztése.
  • CSS Values and Units: a CSS értékeinek (számok, szöveges színek, URL-ek stb.) és egységeinek (px, em, ex, stb.) pontos működését és leírását szabályzó modul.
  • CSS Web Fonts: megszűnt, beleolvadt a CSS Fonts modulba.
  • Behavioral Extensions to CSS: dokumentum elemekhez viselkedések csatolását leíró modul – kvázi új dokumentum elemek hozhatóak létre a segítségével (pl. egy <ledmatrix> elemhez hozzárendelhetünk egy külső URL-en – XBL leírónyelvvel – leírt viselkedést).
  • CSS Flexible Box Layout Module Level 3: elemek box és inline-box megjelenéssel történő renderelését leíró modul.
  • CSS Image Values Module Level 3: képekre hivatkozó CSS tulajdonságok (pl. háttérkép) szabályait írja le.
  • CSS 2D Transforms Module: olyan kétdimenziós transzformációkat ír le, mint a mozgatás, nyújtás, forgatás, torzítás.
  • CSS 3D Transformations Module: perpektívikus 3D alapú transzformációkat ír le, a kétdimenziós transzformációkat ruházza fel egy harmadik dimenzióval.
  • CSS Transitions Module: átmenetek (oldal betöltődéstől kezdve a hover effektekig) viselkedését leíró modul.
  • CSS Animations Module: mozgás és egyéb animáció leírása CSS segítségével: időzítések, állapotok, késleltetések.

Nem mindegyik modult fejlesztik persze aktívan, van, amelyik több éves – vagy azért mert befejezettnek tekinthető, vagy azért, mert nem volt rá komolyabb igény. Számos aktív modulról lehet viszont olvasni manapság, ezek megvalósításánál talán a WebKit (Safari és Chrome mögött) áll az élen.

A fentiekből jól látható, hogy vannak nagyon alapnak tekinthető modulok, melyek jól kidolgozottak, és a CSS filozófiáját, pontos szintaktikáját mutatják be, vagy már évek óta használt, de eddig pontosan nem definiált részleteket szabályoznak.

Összefoglalás

Mint a fentiekből is látható, izgalmas korba születtünk. :) Jópár évnek kell eltelnie, mire a HTML 5 és a CSS 3 többségét használni fogjuk majd tudni, de sok olyan részlet van, melyeket már ma is tudunk használni, vagy mert a “gracefully degradation” jegyében a felhasználó egy tökéletesen működő, csak fapadosabb megoldással találkozik az azokat nem támogató böngészőkben, vagy pedig azért, mert JavaScript vagy más megoldásokkal azokban a böngészőkben is működőképesek lehetnek, melyek alapvetően nem támogatják még azokat. Ahol ez a helyzet, s ahol ebből nem származik komoly hátrány, ott mindenképpen javaslom az újdonságok használatát, hiszen ezzel kényelmesebbé tehető a modern böngészőket használók élete, és látványos megoldásokat lehet kihozni a dologból.

Emlékeimből, illetve a különböző dokumentumokból, blogbejegyzésekből igyekeztem rekonstruálni a történteket, ha valaki másképp tud valamit, ne hezitáljon azt jelezni egy hozzászólás formájában. Folyt. köv.

Closure Compiler

3 Replies

Pár napja tette elérhetővé a Google belső használatú JavaScript könyvtárainak egy részét egy hármas pakkban: a Closure Tools keretében mutatta be a Closure Compiler, a Closure Library és a Closure Templates eszközöket. Az elsőre térnék ki egy kicsit részletesebben, mert egy elég kellemes eszközt kapunk, de nézzük meg azt is, hogy mit tud a többi.

closuretools

A Closure Tools csomag tehát az alábbi összetevőkből áll:

  • Closure Compiler: egy JavaScript “tömörítő”, mely több algoritmus segítségével képes csökkenteni a JavaScript kódok méretét, illetve gyorsítani is azt.
  • Closure Library: a Google saját JavaScript könyvtára, leginkább a Dojo-hoz tudnám hasonlítani, egy a matematikai függvényektől a kommunikáción keresztül a felhasználó interfész elemekig kínál megoldásokat.
  • Closure Templates: JavaScriptben és Javaban megvalósított sablonozó

A Closure Library-re a névterek, illetve az átláthatóságot javító, de sok gépelést igénylő hosszú, angol nyelvű függvénynevek jellemzőek. Személy szerint nem szeretem ezt az irányzatot, én inkább a tömören fogalmazó leíró megoldásokat kedvelem (a Perltől a jQuery-ig), ennek ellenére érdemes vetni a lehetőségekre egy pillantást, mert ha a formátum nem is nyeri el feltétlenül mindenki tetszését, de a lehetőségek kellemesek (mondom ezt úgy, hogy a hasonló névterekkel dolgozó Dojo sohasem tudott meggyőzni).

Amiket kiemelnék a Library nem túl átlátható lehetőségei közül:

  • UI elemek: melyek segítségével a GMailben, GDocsban látható menüt, toolbarokat építhetünk, gombokat tehetünk ki és a Flasht is eltakaró dialógus ablakokat nyithatunk
  • Gyorsbillentyű kezelés
  • Helyesírás ellenőrzés
  • Gears támogatás
  • Böngésző előzmények kezelés

Persze ennél sokkal több van a függvénykönyvtár mögött, az SVN repository-ból sokminden kiderül, és ott a dokumentáció is.

A Closure Template egy sablonkezelő rendszer. Röviden csak annyit írnék róla, hogy szintén nem az ízlésem szerint való, mivel – ha jól láttam – előzetes fordítást igényel (a template-ről JavaScript, illetve Java kódra). Így valóban a lehető leggyorsabb megoldást kínálja, de fejleszteni annyira nem kényelmes a segítségével. Ha már sablonkezelő és JavaScript, akkor nekem a Trimpath-féle megoldás sokkal inkább tetszik.

A Closure Compiler viszont mindenképpen egy hiánypótló eszköz. Komoly optimalizációkat képes végrehajtani a kódon, felismerve a nem használt részeket, az egyszer használt függvényeket megszüntetve, kódrészleteket összevonva, stb.

Az egyszerű whitespace eltávolító (megjegyzések, sortörések, felesleges pontosvesszők) alapszolgáltatásnak számít más optimalizálók esetében is. A bonyolultabb optimalizálók képesek egyebekre is, mint például a változónevek rövidítésére, az objektum["tulajdonsag"] kódrészlet objektum.tulajdonsag formára hozására, stb. A Closure Compiler azonban ennél is továbbmegy, például a következő optimalizációk elvégzésével:

  • if (a) { b(); } -> a && b()
  • if (a) { b(); } else { c(); } -> a?b():c()
  • return 2*3; -> return 6;
  • var a; var b; -> var a,b;

A következő kódrészletből:

function osszeadas(a, b) {
  return a+b;
}
alert(osszeadas(3,8));

Ezt csinálja:

alert(11);

De képes azokat a függvényeket eltávolítani, melyeket nem használunk a kódunkban, így ha nagyobb függvénykönyvtárakkal dolgozunk, nem kell aggódnunk amiatt, hogy felesleges részeket is betöltünk, az optimalizáció során ezeket eldobja ugyanis a program. Itt egy még bonyolultabb optimalizációval is találkozhatunk.

A Closure Compilerről persze el kell mondani, hogy nem feltétlenül biztonságos a használata, bonyolult kódelemzést végez ugyan, de egy eval(), vagy más rossz JavaScript megoldás azt eredményezheti, hogy a végeredmény nem lesz működőképes. Ezt a megfelelő JavaScript kódolási stílus betartásával, konfigurációs paraméterek segítségével (mit engedünk, mely részekre engedjük), a kódban tippek leírásával, vagy a komolyabb tömörítések kikapcsolásával tudjuk kivédeni – értelemszerűen az előbbiek a javasoltak.

Az optimalizáló online (ingyenes), API-val is rendelkező szolgáltatásként, de parancssori eszközként is elérhető. Érdemes játszani vele egy kicsit, látványos. A Firebug kiegészítő segítségével a tömörített kódban előforduló hibákat is könnyen debuggolhatjuk, így az éles rendszerben sincsen kizárva a hibakeresés lehetősége.