Kezdőoldal > HTML 5 > HTML 5 – Start

HTML 5 – Start

2011. április 28. csütörtök Hozzászólás Go to comments

HTML története

A HTML az angol HyperText Markup Language szavak rövidítése. Alapvetően egy leírónyelv, ami weboldalak készítéséhez használunk. A HTML szöveges állomány, amelyet akár egy egyszerű jegyzettömbbel is szerkeszthetünk. A 90 es évek óta 4 végleges változaton vagyunk túl, és most érkezik a HTML5 –ös változata, ami újraértelmezi a HTML-t. Mert immár nem „csak” egy markup leíróról tudunk beszélni, mint ami a HTML4-ig volt. Hanem egy komplett RIA (Rich Internet Application) platformról. Olyan nagy cégek álltak a HTML5 mögé, mint a Microsoft, Adobe vagy a Google. Ők látják, hogy előre mutató technológiáról van szó, ami a piac igényeit átformálja és átdolgozza. A HTML5nek ugyanis meg van az az előnye, hogy szabványos, platform független és nem bontja meg a webes koncepciót. Azaz nem kell külön plugint telepíteni ahhoz, hogy használjuk. Ha a böngésző ismeri a HTML5 szabványt, akkor jól fogja megjeleníteni a számunkra a tartalmat. Ráadásul immár gazdag tartalomról beszélhetünk.

De ne feledjük a HTML5 jelenleg még nincs kész, a szabványosítása még most is tart. Bár már nagyobb változások nem várhatók, de még végleges ajánlás nem készült el.

Ismerkedés a HTML5 alapjaival

Ismerjük meg a HTML5 alapjait, hogy miben hoz újdonságot az oldallá leírása szintjén. Vegyünk a példa kedvéért egy egyszerű oldalt. Általában egy oldalnak van headerje (fejléc) sidebarja (oldalsáv, ahol navigációs elemeket helyezhetünk el például) footerje (lábléce) valamint content (tartalom) része is.

Ezt HTML4 esetében div-ekkel oldottuk meg. Ugyanis speciálisan nem volt footer, header vagy épp article element.

image

Ez így extra munkával járt, hisz ezek gyakori elemek, és külön kellet mindet definiálnunk. A HTML5 tervezésénél viszont megvizsgáltak több millió web oldalt és az eredmény az lett, hogy a legtöbb oldalnál ezeket az elemeket használják. Ezért a HTML5 ezeket az elemeket nyelvi szinten támogatja. Van header, footer, nav, menu, article, section (stb) elementek. Ez a címkézési módszer nem csak azért jobb mert egyszerűbb mint a div-ek használata, de a böngészők is értelmezhetik, hogy milyen strukturális elemről van szó.

Tehát, ha a fentebbi elrendezést szeretnénk az oldalnak adni, nincs más dolgunk, mint a megfelelő elementeket használjuk.

Az előző példa HTML5 elmentekkel:

image

Építsük meg!

Ha HTML5 –ben kezdünk dolgozni, nagyon fontos, hogy az első sorban ezt jelezzük, kell az alábbi elemnettel. (Mint látható, egy DTD-vel Document Type Definitionnal határozzuk ezt meg. Ez biztosítja azt, hogy a böngésző szabványkövető módban értelmezze a weboldalt)

<!DOCTYPE html>              

Amennyiben ezt nem tennénk meg, akkor az oldalunk széteshet, ugyanis a böngésző ilyenkor egy úgynevezett quirks mode-ba kapcsol és magától próbálja értelmezni a kódolást, ami hibás megjelenítést eredményezhet.

Az oldal további részei a következőképpen néznek ki

<html>

<head>

<title>HTML5 Demo</title>

<style>

</style>

<body>

<header><h1>Hello HTML5</h1></header>

<nav><p>Menu</p></nav>

<section>

<p>Section</p>

    <article><p>Cikk 1</p></article>

    <article><p>Cikk 2</p></article>

</section>

<footer><p>Lábléc</p></footer>

</body>

</html>

 

A style rész jelenleg direkt ki van hagyva! (Pontozott rész értelemszerűen nem kell a kódba) Ha most betöltenénk az oldalt, akkor kb. csak egy ilyen egyszerű kinézetett kapnánk.

image

Ez így még nem megfelelő a számunkra. Ezt a stílusokkal tudjuk meghatározni. Sőt immár CSS3 támogatása is van az Internet Exporer 9-es változatnának. (A CSS3 újdonságaival később ismerkedünk meg) De írjuk meg az oldalunk egy alap stílusát. (Figyeljük meg, hogy nem adtuk meg a style-nál hogy miről is van konkrétan szó, csak annyit mondtunk, hogy stílus) Illesszük be az alábbi kódsort a <style> </style> element közé.

body {background-color:white; color: black; text-align:center;}

 

header, footer, nav, section, article {display:block;}

 

header {width:100%; background-color:yellow;}

 

nav {width:30%; background-color:orange;float:left;}

section {width:65%; background-color:SpringGreen ; float:right;}

article {width:70%; margin:2em 10%; background-color:turquoise;}

 

footer {width:100%; background-color:pink; clear:both;}

Látható, hogy immár a headernek, navnak és további elemnek direktbe adunk stílust.

Az oldal kinézete immár az elvárt elrendezést kapjuk.

image

A teljes kód:

<!DOCTYPE html>

<html>

<head>

<title>Basic styling of new structural tags</title>

<style>

body {background-color:white; color: black; text-align:center;}

 

header, footer, nav, section, article {display:block;}

 

header {width:100%; background-color:yellow;}

 

nav {width:30%; background-color:orange;float:left;}

section {width:65%; background-color:SpringGreen ; float:right;}

article {width:70%; margin:2em 10%; background-color:turquoise;}

 

footer {width:100%; background-color:pink; clear:both;}

</style>

<body>

<header><h1>Hello HTML5</h1></header>

<nav><p>Menu</p></nav>

<section>

<p>Section</p>

    <article><p>Cikk 1</p></article>

    <article><p>Cikk 2</p></article>

</section>

<footer><p>Lábléc</p></footer>

</body>

</html>

Header és Footer

A headerbe általában banner, oldal nevet, címet szoktunk belepakolni. Azt is mondhatnánk, hogy headerből vagy footerből elég egy is egy oldalra. De a HTML5 –nél akár több is lehet. Hogy hol van ennek haszna? Nagyon is sok helyen. Például, egy cikknek is lehet fejléce és lábléce.

<article> 

  <header> 

    <h1>Cikk 1</h1> 

    <p>2010. november 1</p> 

  </header> 

  <p>Tartalom</p> 

  <footer>Beküldő: Livesoft Kft.</footer> 

</article>


Ilyenkor a stílusban definiált beállításokhoz képest fog a számunkra megjelenni az oldal.

Elmenetek Internet Explorer 8-al

Fejlesztési szempontból fontos megemlíteni, hogy ha ezt az oldalt meg akarnánk nézni Internet Explorer 8 –al akkor egy széteset oldal kapnánk, ugyanis a 8-as Explorer a HTML5-öt nem támogatja. Így egy kerülő megoldást kell alkalmaznunk.

Ilyenkor az alábbi elemet kell beillesztenünk az oldalunk fejlécébe:

<!–[if IE]> 

<script> 

 document.createElement("header"); 

 document.createElement("footer"); 

 document.createElement("nav"); 

 document.createElement("article"); 

 document.createElement("section"); 

</script> 

<![endif]–>

Elavult elemek

A HTML5-ben közel 100 HTML címke van. De bizonyos elemek kikerültek a HTML 4.01 es változatához képest. Az alábbi elemeket mostantól kerüljük egy webes alkalmazás készítése során.


·         <acronim>

·         <applet>

·         <basefont>

·         <big>

·         <center>

·         <dir>

·         <font>

·         <frame>

·         <frameset>

·         <isindex>

·         <menu>

·         <noframes>

·         <s>

·         <strike>

·         <tt>

·         <u>

·         <xmp>

További újdonságok

A HTML5 rengeteg újítást hozott, nem csoda, hogy ezt a technológiát emlegetik a jövő RIA-jának. Nézzünk néhány lényegesebb újítást még

·         Új szöveges elemek Time, progress, meter,

·         Új tartalom beágyazó elemek: (figure, video, audio, source, canvas, mapaz)

·         Interaktivitást lehetővé tevő elemek: details, command, menu,

·         microdata, adatokat tudunk HTML-be ágyazni

·         HTML és JavaScript kapcsolata, események működése

·         Offline alkalmazások létrehozása

Ezen elemek közül megismerkedünk még néhánnyal.


Advertisements
Kategóriák:HTML 5
  1. 2011. április 28. csütörtök - 12:58

    Arról van valahol releváns infó hogy hogyan állnak a nagyobb böngészők az implementációval?

    Morzel

    • 2011. április 28. csütörtök - 14:23

      Nem tudok róla.

  2. reiteristvan
    2011. április 28. csütörtök - 16:18

    “Olyan nagy cégek álltak a HTML5 mögé, mint a Microsoft, Adobe vagy a Google. Ők látják, hogy előre mutató technológiáról van szó, ami a piac igényeit átformálja és átdolgozza.”

    Ez azért nem ilyen egyszerű, az MS-nek meg az Adobe-nek kb. annyira hiányzott a html5 mint egy nyakonvágás.
    A gugli, apple meg társaik szépen átnyúltak a töketlenkedő w3c felett és belenyomták mindenki képébe az új szabványt. Ugye a gugli jelentős mértékben ott van a web “hétköznapibb” részlegében (pl. youtube) ezért a többieknek muszáj követni ezt a csapásirányt, mert ha a youtube már csak html5 alatt üzemel akkor nem lehet odaállni egy ezt kiszolgálni képtelen explorerrel.

    Ez persze még mindig nem nagy baj, üzlet, én is így csinálnám. A probléma a technológiai oldalon kezdődik, ugyanis a világon semmi nem garantálja, hogy minden böngészőben pont ugyanúgy fog működni minden. Jelen pillanatban a html4/css sem tudja ezt, szóval ez eléggé kétesélyes játék. Nem beszélve arról, hogy mennyi idő amíg a nagyobb böngészők elkészülnek a saját implementációval.

    Ami pedig az előremutató technológiát illeti: amíg marad a javascriptes gányolás addig csak a sz*rt pofozgatjuk, előre biztosan nem haladunk. Ebből a szempontból a SL az ami fényévekre elhúzott minden mástól, más kérdés persze, hogy kell hozzá plugint telepíteni, de ezt a flash is túlélte.

    • 2011. április 29. péntek - 08:13

      Nagyjából egyet értek.

      Még annyit tennék hozzá hogy amíg az van hogy elkészül egy szabvány, nevezzük X-nek.
      Azután A böngésző implementálja x’-t.
      B böngésző implementálja x”-t.
      C böngésző implementálja x”’-t.

      A programozó számára meg nem változik semmi, ugyanúgy gányol mint eddig. A cégek meg egymásra mutogatnak. Mindegyik tábor elmondja hogy a másik a szemét.

      Szóval marad minden a régiben, maximum a doctype lesz lecserélve…

      Morzel

  3. flata
    2011. április 28. csütörtök - 19:50

    Ez például egy feature test (mondjuk elég felületes):

    http://html5test.com/

  4. gabor.orosz
    2011. április 29. péntek - 17:52

    Ez egy elég jó feature test, és a whatwg is nyommal követi hol tartanak a browserek. Itt elég gyorsan frissítenek az új browser verziókkal:
    http://caniuse.com/

  5. gabor.orosz
    2011. április 29. péntek - 18:50

    reiteristvan:
    Két dolgot tennék hozzá. Egyfelől a HTML5 + CSS3 abban különbözik az elődeitől, hogy a szabvány már konkrétan leírja, hogy az adott tag-et a browsernek hogyan, és miképp kell megjeleníteni. Most már nincs olyan, hogy másképp értelmezzék a box modellt, a margint, a paddinget és sok olyat, amitől az oldalak töröttek lettek. Annyi hozzáfűzni való van, hogy ott vannak a browser prefix-ek, amik lehetőséget adnak az újdonságok kipróbálására, kísérletezésre, és az is igaz, hogy így a browser készítők és a designerek hozzáadhatják az ötleteiket, végre nem egy vének tanácsa dönt erről, hanem akik aktívan használják, alkotnak.
    Mellesleg a Silverlight nincs ám annyira a többiek előtt, ahogy azt most próbálod beállítani. Kiemelnék néhány olyan fontos témakört, ahol sajnos nagyon lemararadt, és ezek hiánya is ahhoz vezetett, hogy végül az MS feladta SL-el a web-et:
    – web standards
    – microformats (hCard, vCard, vCal, RSS, Atom, rel-tag)
    – accessibility (WAI-ARIA)
    – SEO
    – Web Typography
    – Facebook Share / Like / +1 integráció
    – support on mobile and tablet devices
    – support on Linux and Mac OSX

    Persze emellett elismerem az SL erejét is, nagyon erős layout területen, hatékony a osztály könyvtára is, sok kiegészítés, control elérhető – itt jegyezném meg, hogy a HTML esetében az utóbbi kettőre ott a jQuery, a jQuery UI és sok plugin – illetve a VS, ami tényleg elég erős, és erre nincs igazi válasz, de ez se minden, jól meg lehet élni nélküle is. 🙂

    Nem vitát akarok indítani, csak felhívni a figyelmet arra, hogy a kép nem annyira egyértelmű, ahogy Te azt leírtad. Mindkettőenek van előnye, és hátránya is, jól meg kell választani, hogy melyik helyzetben, melyiket érdemes választani. Jól megfontolt döntéseket, csak úgy lehet hozni, ha ismerjük az alternatívákat. 🙂

  6. gabor.orosz
    2011. április 29. péntek - 18:51

    Itt érdemes követni a html5 + css3 browser implementációjét:
    http://caniuse.com/

  7. 2011. április 29. péntek - 21:03

    gabor.orosz :

    reiteristvan:
    Két dolgot tennék hozzá. Egyfelől a HTML5 + CSS3 abban különbözik az elődeitől, hogy a szabvány már konkrétan leírja, hogy az adott tag-et a browsernek hogyan, és miképp kell megjeleníteni. Most már nincs olyan, hogy másképp értelmezzék a box modellt, a margint, a paddinget és sok olyat, amitől az oldalak töröttek lettek. Annyi hozzáfűzni való van, hogy ott vannak a browser prefix-ek, amik lehetőséget adnak az újdonságok kipróbálására, kísérletezésre, és az is igaz, hogy így a browser készítők és a designerek hozzáadhatják az ötleteiket, végre nem egy vének tanácsa dönt erről, hanem akik aktívan használják, alkotnak.
    Mellesleg a Silverlight nincs ám annyira a többiek előtt, ahogy azt most próbálod beállítani. Kiemelnék néhány olyan fontos témakört, ahol sajnos nagyon lemararadt, és ezek hiánya is ahhoz vezetett, hogy végül az MS feladta SL-el a web-et:
    – web standards
    – microformats (hCard, vCard, vCal, RSS, Atom, rel-tag)
    – accessibility (WAI-ARIA)
    – SEO
    – Web Typography
    – Facebook Share / Like / +1 integráció
    – support on mobile and tablet devices
    – support on Linux and Mac OSX

    Persze emellett elismerem az SL erejét is, nagyon erős layout területen, hatékony a osztály könyvtára is, sok kiegészítés, control elérhető – itt jegyezném meg, hogy a HTML esetében az utóbbi kettőre ott a jQuery, a jQuery UI és sok plugin – illetve a VS, ami tényleg elég erős, és erre nincs igazi válasz, de ez se minden, jól meg lehet élni nélküle is. :)

    Nem vitát akarok indítani, csak felhívni a figyelmet arra, hogy a kép nem annyira egyértelmű, ahogy Te azt leírtad. Mindkettőenek van előnye, és hátránya is, jól meg kell választani, hogy melyik helyzetben, melyiket érdemes választani. Jól megfontolt döntéseket, csak úgy lehet hozni, ha ismerjük az alternatívákat. :)

    Ez tökéletes így van. A HTML5-nél tanultak az előző verzió hibájából, és ez egy fontos tervezési szempont volt.
    Gabi szép megfogalmazás 😉

  8. gabor.orosz
    2011. április 29. péntek - 22:11

    Igen, ez így van, de még annyit hozzá tennék, hogy mindezt additív módon tették, csak bővítették a szabványt, reagáltak gyakran előforduló problémákra, amelyeket bár eddig is meg lehetett oldani több-kevesebb JS kódolással, vagy ideális esetben jQuery plugin is volt hozzá… mostantól viszont ez deklaratív.

    A poén, hogy teljes mértékben az előző verziókra épít, azokat is simán megjelenítik az új motorok, viszont a sok új elem, sok új szemantikai lehetőséget is ad, amelyek helyes használatáért a mind a képernyő olvasókkal dolgozó csökkent látó képességű emberek, mind a világ legfontosabb “vak böngészője” a Google kereső robotjai hálásak lesznek. És akkor még a microformat-okról még megse emlékeztünk, azokkal aztán komoly lépéseket tehetünk a szemantikus web irányába. 🙂

    Itt javítanék is egy hibát a cikkben, ugyanis arról van szó, hogy bizony nem került ki egyetlen régi tag sem a specifikációból, mindössze az történt, hogy megjelölték őket egy obsolate flagel, ezzel jelezve a designereknek, hogy ezt lehetőleg ne alkalmazzák, és ha már azt láthatják, hogy kellően alacsony számban van alkalmazva, akkor a szabvány egy későbbi verziójában kigyakják. Fontos, mert ezzel a nyelv tisztul, és egy fokozatos, kíméletes átmenetben ezek a rossz részek kivezethetők.

    És ha már obsolate, akkor a w3 validátora sokat segíthet majd egy szép markup elérésében (a html5 esetében még experiemental a cucc):
    http://validator.w3.org/

  9. gabor.orosz
    2011. április 29. péntek - 22:58

    Sokan érvelnek a HTML5 + CSS3 ellen úgy, hogy bizony még nincs kész, a browserek is össze vissza támogatják, és így nem lehet jól, vagy egyáltalán használni. A poén az, hogy kis fantáziával simán lehet. Az új feature-ök java additív módon lett bevezetve (vannak teljesen újak is, de ezek se zavarnak be), ezért ha a kedves fejlesztő megfelelően tervez, és ért a dologhoz, akkor semmi komoly probléma nem történhet.

    Tegyük fel van egy névjegykártyám, aminek az alapja egy szabványos vCard formátum. Kezdésként kaphatna némi margin-t, és padding-et, egy könnyed bordert, háttér színt, lehet formázni a szöveg elrendezését ez eddig tiszta, teljesen szabványos, szinte mindenhol működik.

    De lépjünk tovább, jöhet egy háttérkép, némi web-font, kerekítsük le a keretet, adjunk hozzá némi árnyékot, forgassuk el, majd végül valami 3D transzformáció. Ez a második blokk már kicsit problémásabb, lehetséges, hogy egyiket, vagy másikat, már nem tudja minden böngésző kezelni, de mi van akkor ha nem? Hiányozni fog egyik-másik effekt, de ettől még az egész design nem lesz törött. Gondoljátok csak át, mi lesz ha nem működik az árnyék? Vagy a font nem stimmel? Ugye hogy nem vészes.

    A technikát Progressive Enhancement-nek hívják. Egy MItch Hedberg nevű komikus mondata nagyon jól megfogja a helyzetet “An escalator can never break; it can only become stair.”. És tényleg, körültekintően építkezünk, miszerint a HTML csak a document modelt adja, a HTML5 új elemei nagyban elősegítik a jobb szemantikát, a CSS-el erre fokozatosan lépésről lépésre építkezik,és végül JS + jQuery adhatja még ehhez hozzá. Ha az ember ért hozzá, ez egy pazar MVC modellt ad. A szép az egészben az, hogy akár a TV-k esetében, a gyengébb képességű browserekel mindig elvesztünk egy kicsit, de a lényeg, a tartalom megmarad. 🙂

  10. reiteristvan
    2011. május 1. vasárnap - 05:55

    Elnézést a hosszú válaszidőért, tegnap megírtam aztán egy jó kis áramszünet úgy döntött, hogy mégsem 🙂

    “Két dolgot tennék hozzá. Egyfelől a HTML5 + CSS3 abban különbözik az elődeitől, hogy a szabvány már konkrétan leírja, hogy az adott tag-et a browsernek hogyan, és miképp kell megjeleníteni. Most már nincs olyan, hogy másképp értelmezzék a box modellt, a margint, a paddinget és sok olyat, amitől az oldalak töröttek lettek.”

    Most őszintén: eddig miért nem ültek össze a gyártók egy vonalzóval a kezükben, hogy lemérjék mennyi egy pixel? Mert nem áll érdekükben. Az IE azért nem csinálja mert így lehet mutogatni a többiekre, hogy ők másmilyenek, mindenki más pedig szidhatja az IE-t mert nem úgy működik ahogyan azt elvárják.
    Na most, tegyük fel, hogy valami csoda folytán mégis betartják a szabványt, kisbetűs résszel együtt. A probléma akkor is az, hogy négyen négyfelé fejlesztenek. Mondok egy példát: ugye a html5 behoz mindenféle multimédiás vackot, amik előszeretettel gyilkolják az erőforrásokat. Képzeljük el, hogy az IE csapat kidolgoz valami überbrutál algoritmust, amely segítségével kétmillió fps-sel játszik le mindent, simán viszi a doom49-t. Mindenki más persze 1-2 fps-t tud csak.
    A baj, hogy ez – ha nem is ennyire extrém méretben – teljességgel reális lehetőség, sőt a mai napon is vannak olyan html5 demók amik egyik vagy másik böngésző alatt futnak csak tökéletesen.

    “Mellesleg a Silverlight nincs ám annyira a többiek előtt, ahogy azt most próbálod beállítani. Kiemelnék néhány olyan fontos témakört, ahol sajnos nagyon lemararadt, és ezek hiánya is ahhoz vezetett, hogy végül az MS feladta SL-el a web-et:
    – web standards
    – microformats (hCard, vCard, vCal, RSS, Atom, rel-tag)
    – accessibility (WAI-ARIA)
    – SEO
    – Web Typography
    – Facebook Share / Like / +1 integráció
    – support on mobile and tablet devices
    – support on Linux and Mac OSX”

    Félreértés vagyon. Nem arra céloztam, hogy az SL bármilyen módon felválthatja a html-t. Éppen hogy fordítva van, szegény html-t szeretnék úgy megerőszakolni, hogy felvegye a versenyt a másik két RIA megoldással.
    Amire én gondoltam, az az, hogy az SL technológia szempontjából elhúzott a többiektől és ez bizony igaz is.
    Az viszont tény, hogy a hétköznapi felhasználók körében nem aratott zajos sikert, de van egy terület a hol igenis verhetetlen: LOB.
    Amúgy istenigazából én nem éreztem, hogy a SL-t annyira propagálták volna a hétköznapi felhasználás irányában. Esetleg a kettőnél ez még felfedezhető volt (és az valóban nem is volt olyan nagyon jó), de a három óta egyértelműen a vállalati szféra van megcélozva.

    “Persze emellett elismerem az SL erejét is, nagyon erős layout területen, hatékony a osztály könyvtára is, sok kiegészítés, control elérhető – itt jegyezném meg, hogy a HTML esetében az utóbbi kettőre ott a jQuery, a jQuery UI és sok plugin ”

    Pont ez a baj, a sok plugin. Nem beszélve arról, hogy a jQuery és az összes többi ilyen okosság független a gyártóktól, nem lát bele, mondjuk a js feldolgozó forráskódjába, nem tudja tökéletesen optimalizálni a kódot.

    “Ez tökéletes így van. A HTML5-nél tanultak az előző verzió hibájából, és ez egy fontos tervezési szempont volt.”

    Ez egészen pontosan hol látható? A html4-nek (sőt az egész html-nek) egyetlen hibája volt/van: nem arra használják amire ki lett találva. Persze, jó a html5 vannak pozitív tulajdonságai és kellett a fejlődés, de nem ott jön a változás ahol igazán szükség lenne rá, nevezetesen az alapoknál: a html+js kombó egészen egyszerűen alkalmatlan arra, hogy komoly GUI-t lehessen építeni.
    De mondok jobbat: a böngészők brutális erőforrásigénye. Egy átlag weboldal megjelenítése böngészőtől függetlenül 30-60 megabyte memóriát igényel. Kérdem én, mi a jó isten visz el ennyit? Rendering engine, extension-ok, etc, etc, etc… Ezt biztos, hogy nem lehetne jobban csinálni? Nem lehet oda visszavezetni a hibát, hogy egy közel két évtizedes szörnyeteget foltozgatnak összevissza? Átlag havonta jön a frissítés a böngészőkhöz, hogy 1000%-kal gyorsabban dolgoz fel js-t – persze, csak közben isten gépe kell a rendes futtatáshoz (ráadásul kivétel nélkül az összes szivárog mint az állat).

    “Sokan érvelnek a HTML5 + CSS3 ellen úgy, hogy bizony még nincs kész, a browserek is össze vissza támogatják, és így nem lehet jól, vagy egyáltalán használni. A poén az, hogy kis fantáziával simán lehet.”

    Igen, ezt hívják gányolásnak. Tessék eldönteni, hogy szabvány van vagy fantáziálunk – a kettő együtt nem megy. Félkész rendszert nem használunk. Pont.

    “Gondoljátok csak át, mi lesz ha nem működik az árnyék? Vagy a font nem stimmel? Ugye hogy nem vészes.”

    Ezt légyszíves mond majd el az ügyfélnek is aki habzó szájjal veri az asztalt, hogy nem ezért fizetett.

    Ne értsetek félre, nem rosszindulatból mondom amit mondok, egyszerűen nem tetszik ez a hype amit a html5 körül csap a világ. Még évekig nem lesz belőle semmi, de máris valamiféle messiásként kezeli mindenki. Én is azt gondolom, hogy jó dolog a fejlődés, de még nagyon messze van az alagút vége.

  11. Zoli
    2011. május 1. vasárnap - 09:59

    Hú tegnap este kellett volna írnom, mert így semmi sem maradt 😀 az a szitu, hogy közel 100%-ban egyet értek Istvánnal.

    Szögezzünk le egy dolgot, és szerintem itt most István nevében is beszélhetek talán (a következő egy mondatra nézve). TUDJUK, hogy a html5 a jövő, tudjuk, hogy a Silverlight gyakorlatilag lejött a webről. De azt is tudjuk, hogy marketing szöveggel nem lehet védeni egy technológiát…
    “Gondoljátok csak át, mi lesz ha nem működik az árnyék? Vagy a font nem stimmel? Ugye hogy nem vészes.”
    “s ha már obsolate, akkor a w3 validátora sokat segíthet majd egy szép markup elérésében”
    “ha a kedves fejlesztő megfelelően tervez, és ért a dologhoz, akkor semmi komoly probléma nem történhet.”
    “Most már nincs olyan, hogy másképp értelmezzék a box modellt, a margint, a paddinget és sok olyat, amitől az oldalak töröttek lettek. Annyi hozzáfűzni való van, hogy ott vannak a browser prefix-ek, amik lehetőséget adnak az újdonságok kipróbálására, kísérletezésre….”

    Nem hiszek a fülemnek (illetve a szememnek) Gabi… előbújt belőled az MS-es diáktanácsadó vagy mi? 🙂 Ez bullshit…
    1. Másképp értelmezik, ahogy nekik jó, mert ők a böngésző gyártók, a fejlesztők 90%-a meg amúgy is hülye, meg gányol, meg garázsdev, meg jézusom… Lefestetted azt, hogy a html5 hogyan fest egy szép utópisztikus világban, ami soha nem jön el…
    Amig létezik böngésző verseny, amíg egy félkész technológiára készülnek website-ok, amíg idióták is programozhatnak weboldalakat, addig a html5 pont ugyanolyan sz*r lesz, mint korábban volt…

    Az érvelésem többi részét István már nagyon jól leírta… még hozzá tenném, hogy erős absztrakció (ezredik library, ami elfed vmit…), tooling hiány és fejlesztési szempontból kollaboráció hiánya jellemzi erősen a platformot… Ez utóbbi kettővel arra gondolok, hogy ki csinálja az animációt? A fejlesztő? Tényleg képes a dinamikáját pontosan megállapítani? Mert a designer biztos nem fog JS-t írni… vagy majd pingpongoznak a paraméterekkel ide oda? Ezt a blend pl jól megoldotta (remélem, erre lesz vmi megoldás….)
    A html5 tervezésének messze egyik legnagyobb hibája, hogy az animációkat nem oldották meg deklaratív módon… (mert 1. lenne hozzá rendes tooling, 2. Nem a fejlesztőre bízták volna, hogy optimális kódot írjon…)

    Mondhatnánk hogy depressziós realista vagyok, de szvsz a html5 alapú fejlesztés, pont semmivel sem lesz jobb, mint a html4 alapú volt… meg tudsz csinálni extra dolgokat benne a html4-hez képest… (azaz ahogy István is mondta a korábbi ria platformokhoz próbálják felhúzni a html-t)

    Ja és még valami:
    “Kiemelnék néhány olyan fontos témakört, ahol sajnos nagyon lemararadt, és ezek hiánya is ahhoz vezetett, hogy végül az MS feladta SL-el a web-et…”
    Szerintem meg baromira nem lemaradásról van szó… csupán fókusz csere… a Microsoft-nak a html5 szerintem baromi jól jött!! Van egy platformja… a neve ASP.NET (MVC) a másik az internet explorer… ennél jobb hír ezeknek a területeknek nem is kellett… remélem nem kell elmagyaráznom miért… html5-tel nagyon erős triót alkothatnak majd! Az SL-t a microsoft már elég rég desktop/device világba akarja vinni… Gondoljatok a WPF-re… ő volt előbb… de a flash-re alternatívát kellett nyújtani… de szerintem most a Microsoft az aki a legjobban tapsikol a html5 miatt… és szépen bepozícionálja az SL-t a desktop / mobile (és remélhetőleg tablet) világba is… én pl már azt is várom egy ideje, hogy hirtelen az xbox dashboard-ra is SL-ben lehessen fejleszteni!

    Konklúzió: A web jövője a html5, de azért álmokba nem ringassuk magunkat, jobb nem lesz ez semmivel. (fragmentáció, fragmentáció, fragmentáció)

  12. Zoli
    2011. május 1. vasárnap - 10:05

    Ha engem kérdeztek nagy szükség lenne arra, hogy valaki kiálljon _Őszintén_ és elmondja, hogy mi a helyzet. Parasztvakítás helyett tényleg elmondja, hogy mik a lehetőségek, mik a veszélyek, mik a határok. És arra is kéne valaki, hogy MEGMUTASSA a hogyant….

  13. gabor.orosz
    2011. május 1. vasárnap - 12:05

    Akkor rögtön tegyünk rende egy félreértést, nem a hype fenntartása a célom, a HTML5 is csak egy technológia a sok közül, a Silverlight is az, amit lehet szeretni, és utálni is, vannak hibái, és pozitívumai is bőven mindkettőnek. Ne essünk abba, a hibába amikor az egyetlen szerszámunk a kalapács, és akkor már minden amit látunk az szög. Ez az ipar sokkal árnyaltabb ennél, és ez így van jól.

    És ha már pozitív és negatív tulajdonságok, van a HTML5+CSS3+JS triónak sok szempontból baja, könnyedén lehet rosszul használni, amit sokan meg is tesznek, erre nem is kell példákat mutatnom. Azzal viszont vitakoznék, hogy nem lehet komoly GUI-t építeni, az a helyzet, hogy bizony lehet, és nem is akármilyeneket. Csak néhány példa, és még bőven lehetne válogatni:
    http://www.sidlee.com/#
    http://www.airwalk.com/
    http://www.nikebetterworld.com/

    A kérdés leginkább az, és itt van a kutya elásva, hogy mint minden eszközt, ezt is meg kell tanulni jól használni, hogy jó eredményt kapj. Nagyon sok technika van arra, hogy jó oldalakat építs, és ehhez bizony tanulni kell. Ez igaz az SL-re is, ránézésre nem lesznek ott se jó alkalmazások, rá kell érezni sok technológia helyes használatára, az MVVM-re… stb.

    Elismerem, hogy vannak itt problémák, mint a produktivitás, vagy épp a böngésző fregmentáció. De ezekre vannak technikák, technológiák. Ha megvan az a kellő tudás, akkor szerintem ez is egy hatékony platform lehet. Szívesen mutatok is majd erre technikákat, hogyan lehet úrrá lenni ezen, és a HTML5 valóban úgy működhessen, ahogy az hivatott. Innentől már csak tanulás és nyitottság kérdése, viszont egyáltalán nem kötelező, el is lehet fordulni. De csak egy kérdés: érdemes? 🙂

    A fejlődés itt van, jön megállíthatatlanul, és fejlődik az egész bolond módon. Ez persze fregmentációt is hoz magával, kicsit eltérnek a böngészők, de pont ennek a megelőzésére vannak kitalálva az egyes modulok, és ezért priorizálták őket. A legnagyobb böngészők készítői tartják is magukat ehhez. Így additív módon be is lehet vezetni az egyes új képességeket. Persze mindig lesznek eltérések, de mivel gyors a fejlődési ciklusuk, ez nem túl sokáig probléma, pár hónapos eltérésekkel javában ugyanazokat az új képességeket hozzák be. És ugyanúgy optimalizálják mondjuk a JavaScript feldolgozókat, de sok mást is.

    A legfőbb kivétel, amivel az MS nagyot akart pucsítani, az a WebGL, és ezek azok a demók, amik szana szét fognak esni a többi böngészőben. Ezt egyelőre én nem is nézem, de még ott van 1000 másik kiváló új képesség, ami plusszt hoz, és igenis feldobja a contentet.

    Ettől eltekintve se akkor nagy a szakadék már a böngészők képességei között mint korábban voltak (értem itt a 4 nagy bőngésző friss változatait), és haladnak azért a szabványos út felé, és másképp próbálnak kitűnni. Az az igazság, hogy nincs más út, még az MS-nek se, mert már nincs akkora ereje a web-en. Másfelől a többieknek is érdeke a Google-nek és a Facebooknak is pláne, aki a stratégiáját a web-es alkalmazásokra építi, egyszerűen kell a szabványos platform, hogy fejlesztőik és ezeken keresztül megfelelő alkalmazásaik legyenek. Változtak az idők, nagyon, és bár a kép sose lesz teljesen idilli, de _nagyon_ sokat javult.

    A HTML5 mellett ugye ott vannak az olyan technológiák is mint a jQuery, és még nagyon sok más társa is. Mivel open source, így az kapcsolódik be aki akar, akár a böngésző gyártók is, így például a jQuery, Dojo, vagy Prototype esetén a Google, a Mozilla és az Opera is képviselteti magát, nem kizárt, hogy az MS (biztos vagyok hogy másképp nem építkezne egyik másik technikára, ha nem lenne benne érdekeltsége). Így igazából ismerik is, és valamennyire tudnak optimalizálni is. 🙂

    És egy legutolsó gondolat. Az ügyféllel meg lehet tanulni kommunikálni, és meg is kell, ezen sok áll vagy bukik… sőt mi több, ezt folyamatossá kell tenni. Amikor elkezdődik a közös munka, az első skiccek asztalra tételénél ezt a témát fel kell hozni, hogy itt van a sok új browser, a mobil eszközök, aztán a háttérben a régi böngészők a maguk elég alacsony %-ékukkal. El lehet mondani, hogy melyik mire képes, mit lehet kihozni belőle, azt is hozzá lehet tenni, hogy a régiek mit nem tudnak alapból, mondjuk nem lesz árnyék… persze ezt is meg lehet csinálni, de az mondjuk x nap munka. És közösen lehet döntést hozni, hogy mi éri meg, és mi nem. Nem lehet eléggé hangsúlyozni a helyes, és érett kommunikáció lényegességét… ha minderről előre tud, és le is van írva, akkor a legtöbbnek nem lesz baja (sőt!), ha viszont utólag szembesül az ilyenekkel, akkor teljesen jogosan üti az asztalt, én is azt tenném.

  14. gabor.orosz
    2011. május 2. hétfő - 09:58

    Atis: A tegnapi hozzászólásom ugye meg fog jelenni… köszi! 🙂

    • 2011. május 2. hétfő - 10:08

      Már itt is van 🙂 Csak valamiért Spam-be tette.

      • gabor.orosz
        2011. május 2. hétfő - 17:29

        Semmi gond… köszi! 🙂

  15. gabor.orosz
    2011. május 2. hétfő - 17:46

    Zoli:
    Lássuk sorban azokat azokat a marketing szövegeket.

    1. “Gondoljátok csak át, mi lesz ha nem működik az árnyék? Vagy a font nem stimmel? Ugye hogy nem vészes.”

    Had mutassam be a problémát egy másik iparág szempontjából, akik egyfelől egy nagyon hasonló problémán vannak túl – másfelől néznek szembe újra vele – egy olyan megoldással, amivel igazából nagyon sokan együtt tudnak élni. Adottak ugye a televíziók, kezdve a fekete-fehérektől, a 10-15 éves színes CRT-en át, egészen napjainkig, amikor a HD Ready vagy Full HD készülékek fedik le a piacot. Ugye a képességek teljesen mások, ahogy a kedves tulajok pénztárcái is.

    Nyilván a különbségek okán reménytelen az, hogy mindenki ugyanúgy kapja meg, UGYANAZT a tartalmat. A megoldásuk teljesen huszáros, mindenkinek ugyanazt a tartalmat küldik, a jelek a vezetékben tök ugyanazok, csak épp mindenki annyit lát belőle, amennyit az eszköze megenged. És ezt az emberek elfogadják, sőt ismerve a készülékük képességeit nem is ágálnak, inkább aki megteheti csendben megveszik az újatt \ jobbat. Lehet szépíteni, toporzékolni, de ez így van.

    Egy felől igazat adok Istvánnak, valóban az asztalt fogja verni az ügyfél, ha azzal szembesül, hogy az egyik böngészőben kerek az a border, ellenben a másikban nem az. Átverve fogja érezni magát, totál jogosan!

    Sokan itt követik el a dolgot, és ezért szar a web-fejlesztés, mint szakma megítélése. Viszont, fordítsuk meg a dolgot, gondolkodjunk kicsit másképp, kezeljük az ügyfelet felnőttként, és magyarázzuk el neki, hogy mit fog kapni a pénzéért. Fel kell neki vázolni már az alapoktól, hogy néz ki az eszközök és böngészők repertoárja. Ami jól néz ki 22″\24″-on, az nem fog egy telefonon vagy egy tableten. Például egy nagy, sok oszlopos táblázat az utóbbiakon egész biztos nem lesz jól olvasható… ott bizony át kell szervezni a megjelenítést.

    (Itt jegyezném meg, hogy a CSS3 elég komoly támogatást kínál erre: CSS3 Media Query néven. Csak egy link: http://www.w3.org/TR/css3-mediaqueries/ Jelenleg is több böngésző támogatja, beleértve az iOS-t és az Android-ot is támogatja ezt a CSS3 modult-t.)

    Tovább lehet menni, lehet vázolni az ügyfélnek, hogy léteznek új (Chrome, Firefox, Safari, Opera, IE9), és régiek is (IE6, IE7, IE8). Ezen felül ezek rendelkeznek ilyen olyan piaci részesedéssel .

    (Ezeket a statisztikákat elég komolyan vehető szervezetek teszik az asztalra, nem kell hasra csapni se, néhány példa erre:
    http://www.w3schools.com/browsers/browsers_stats.asp
    http://www.w3schools.com/browsers/browsers_explorer.asp
    http://www.upsdell.com/BrowserNews/stat.htm#source1

    És még sok másik is van, akár országokra, akár nagy oldalak látogatási adataira rászűkítve, így lehet a client piacához a legjobban hozzáilleszteni. Ez pedig kifejezetten az IE6-ra kihegyezve, az MS szerint:
    http://www.theie6countdown.com/default.aspx)

    Lehetséges megoldás, miszerint az első tervek bemutatásánál már jelezzük azt, hogy a szépen kinéző tervekből melyik mit tud megjeleníteni (sőőőt, akár prototípussal demonstrálható is). Hangsúlyozni kell hogy az oldal nem lesz törött, az eleve ELFOGADHATATLAN, egyszerűen hiányozni fognak ezek a plusszok. Garantálom, hogy sok user észre se fogja venni, hogy nincs ott az árnyék, vagy nincs a doboz lekerekítve. Ellenben a layout, és a tartalom érintetlen lesz.

    (Erre is vannak eszközök, itt is van kettő: http://code.google.com/p/html5shiv/, http://www.modernizr.com/ Segítenek abban, hogy a régi browsereken se legyen törött az élmény, és használhasd a HTML5 + CSS3 elemeket… persze ez sem tanítja meg őket arra, amit nem tudnak.)

    Tehát: kommunikáció, kommunikáció, kommunikáció… tudják mire számíthatnak, és nem érzik magukat átvágva. Ha előre tisztázva van, hogy az ügyfél fontosnak tartja az IE6 támogatást, akkor az lesz. De azt is választhatja, hogy a modern browserekre hegyezd ki faszán. Vagy lehet, hogy az IE6 gányolás helyett adott büdzséből azt kéri, hogy az ügyfélköre sajátosságai okán legyen fasza iPad-en is. Neki kell eldönteni, hogy nála mi a nyerő stratégia, hol a legmagasabb a ROI, te csak tanácsot adhatsz.

    (folyt. köv.)

  16. gabor.orosz
    2011. május 3. kedd - 09:10

    (Mielőtt még tovább mennék, eszembe juttot még egy jó egy igazán jó példa a CSS3 Media Queries használatára, ez pedig nem más mint az index.hu mobil oldala. Egy kellemes, egyszerűsített felületet ad iPhone-on és Androidon, támogatja az elforgatást, álló és fekvő nézetben is igényes képet ad. Fekvő esetén szépen alkalmazza a 2 oszlopos multi-column layout-ot. Megjegyzem, mindezt most már CSS3-ból, teljesen deklaratívan megoldva, extra JavaScript kód nélkül.)

  17. gabor.orosz
    2011. május 3. kedd - 10:54

    2.\ “s ha már obsolate, akkor a w3 validátora sokat segíthet majd egy szép markup elérésében”
    A cél itt pedig egyértelműen az, hogy a HTML5 sokkal fókuszáltabban egy dokumentum leíró nyelv legyen, lehetőség szerint megszabadulva az elavult, rossz részektől, illetve ezen felül az összes a megjelenítést, és viselkedést befolyásoló elemtől.

    Így elkerülhető lesz a keveredés, ha követjük az ajánlásokat, akkor lényegesen egyszerűbb, letisztultabb kódot kapunk, konzisztensebb lesz az egész, nem lesz az a spagetti kód érzet.

    (Példának okáért sok más egyéb mellett:
    – A body, vagy a table-ök formázásai ilyen attribútumok, amelyek CSS-el könnyedén pótolhatóak.
    – Ahogy a frame-ek teljes egészében is, CSS-el is kezelhetőek.
    – Az applet-ek a többi beágyazott, futtatható objektumhoz hasonlóan, konzisztens módon lesznek kezelve.
    – Számos meta információt – mint a http-equiv, vagy tpye – kivágtak, mivel a böngészőknek nincs szüksége ezekre az infókra.)

    Nem új problémáról van itt szó, rég felismerték, hogy a nyelv maga egy alapos plasztikai műtétre szorul. Sokkal precízebben kell leírni, fókuszáltabban kell a cél felé mutatni. Ha jobban a hátterébe gondolsz az egésznek, akkor az egész mögött nincs másról szó, minthogy egy óriás API change-et akarnak végrehajtani több lépésben.

    Lehet ezt a döntést sok szempontból ütni, de én személyesen nem látok más komolyan vehető választást, ami segíthetne. Az nem opció, hogy egyik napról a másikra kivezetni a nyelvből a felsorolt elemeket, egészen addig a pontig, amíg relatíve magas az elterjedtsége az oldalakon. Az pedig végképp nem, hogy ennél is tovább menjenek.

    (Többek között a Google folyamatosan statisztikákat csinál az általa index-elt, és cache-elt oldalakon többek közt arról is, hogy az egyes HTML elemeknek mekkora az elterjedtsége, így folyamatosan tudják követni az eredményeket.)

    A legjobb, amit tehetnek ennek érdekében, hogy sok elemet obsolate-nak jelölnek, és terjesztik ezt az üzenetet, mégpedig úgy, hogy leírják a szabványban, cikkeznek róla akár 1000x is, tanítják folyamatosan, videókban emlegetik, warningot adnak az validatorok… stb. Ezen felül a nagyok maguk is vállaltan kivezetik ezeket az elemeket a saját tooljaikból és oldalaikról.

    Folyamatosan figyelik ezután a statisztikákat, és ha már a saját, illetve a nagy látogatottságú, óriás oldalakról eltűnnek, kellően alacsony az elterjedtsége, akkor lehet lépni, és valamelyik következő verzióban az égig rúgni őket.

    Miért is ne válhatna be? A legrosszabb, amit tehetnek, hogy ülnek és nem csinálnak semmit. Könnyű legyinte, és azt mondani, hogy úgy se lehet jobb, de itt látható, hogy sok ember keményen dolgozik azért, hogy igenis jobb legyen.

    (Itt olvashatók cikkek, amik a döntések hátterét taglalják:
    http://www.w3.org/TR/html5/obsolete.html
    http://www.paulwallas.com/html5/html5-obsolete-and-deprecated-elements/
    http://www.html-5.com/changes/deprecated/)

    (folyt. köv.)

  18. gabor.orosz
    2011. május 3. kedd - 12:41

    3.\“ha a kedves fejlesztő megfelelően tervez, és ért a dologhoz, akkor semmi komoly probléma nem történhet.”
    “Másképp értelmezik, ahogy nekik jó, mert ők a böngésző gyártók, a fejlesztők 90%-a meg amúgy is hülye, meg gányol, meg garázsdev, meg jézusom… Lefestetted azt, hogy a html5 hogyan fest egy szép utópisztikus világban, ami soha nem jön el…
    Amig létezik böngésző verseny, amíg egy félkész technológiára készülnek website-ok, amíg idióták is programozhatnak weboldalakat, addig a html5 pont ugyanolyan sz*r lesz, mint korábban volt…”

    Ezt rögtön több oldalról is megnézném.

    I. \ Először is őszintén mondom, ezt egy kicsit megmosolyogtam, szerintem nem technológia függő, mindenhol akadnak szép számmal idióták. Véleményem szerint egy igazán komolyan vehető programozó ember jól boldogul mindkettővel (sőt bármi mással is), a többiek mindkettővel szemetet fognak gyártani.

    Oktat(t)unk mindketten, találkoztunk bazi sok emberrel, és garantálom, hogy a .NET \ SL se véd meg hosszú távon az idiótáktól, a garázsdev-től, vagy épp a szemét, sz*r gyártástól.

    De nézz körbe, azon oldalak közül, amiket Te is látogatsz, sokkal több a jól megcsinált, mint ami nem az… ami igazán szar, az jó eséllyel a szemed elé se nagyon kerül (persze vannak kivételek, mindig lesznek).

    II. \ A VS10 + Blend designerek, a WebMatrix-ok, vagy épp a LightSwitch-ek védeni fognak egy darabig, de csak ideig-óráig segítenek, és amint elfogy ez a támogatás a hátuk mögött, és olyan dolgot kell csinálni, amit azok nem támogatnak, akkor bizony kézzel kell ám folytatni, és onnan következnek az igazán ordas hackelések.

    Egyébként itt is megtalálhatóak a designer támogatások egy darabig, és bár nem olyan fejlettek, mint például a Blend, de sokat tudnak segíteni. Példaképp néhány program, amiket ismerek, és jók:
    http://www.adobe.com/hu/products/dreamweaver.html
    http://macrabbit.com/cssedit/
    http://macrabbit.com/espresso/
    http://www.netbeans.org/
    http://www.macromates.com/

    A böngészők is nagyon sok olyan képességgel rendelkeznek, amelyek elősegítik a fejlesztést:
    – források áttekintése,
    – dom
    – debugging,
    – profiling (cpu, memory, network)

    Ezeket mát az összes modern eszköz támogatja.

    III. \ Mindezek mellett az még nagyon sokat segíthet, ha az oldal építésénél rögtön egy megfelelő alapból indulunk ki. Például ebből:
    http://html5boilerplate.com/
    Ezt használva máris úgy indulhatunk, hogy egy olyan alapunk van, amit jól állítottak össze, sok kompatibitási problémát rögtön az elején lekezelnek, illetve a leggyakrabban használt eszközöket alapból megkapjuk, tehát az oldal összeállítását rögvest megkönnyíti, és jelentősen gyorsítja is.

    Másfelől az is sokat segít, ha rögtön az elején a böngészők estlegesen eltérő beépített stíluslapját egységesre reseteljük:
    http://meyerweb.com/eric/tools/css/reset/

    Ezek nagyban segítenek abban is, hogy a böngésző fregmentációs problémákat csökkentsék.

    IV. \ Szintén nagyon sokat segít, ha ahelyett, hogy egyből őrült módon JS kódolásba kezdenénk, előtte egy kipróbált JS Library-t vetünk be. A következők sokszor kipróbált, bizonyított darabok, amelyek mögött nagyon komoly cégek állnak, tehát nem lesznek egyhamar lehúzva a WC-n:
    http://jquery.com/
    http://www.dojotoolkit.org
    http://www.prototypejs.org
    http://mootools.net/

    Megjegyzem, hogy ezek mindegyike jól működik az összes böngészőn, még az IE6-on is.

    V.\ A böngészők folyamatosan fejlődnek, hónapról-hónapra rengeteg új feature-t hoznak. Ez nem fog elmúlni, így működik ez az új és csúnya agilis világ. Arra is fel lehet készülni, hogy nem lesz megállás, ha elkészül a HTML5 majd jön az utódja, ezzel meg kell tanulni együtt élni, elfogadni, mivel nincs más választás. Ellenben van sok tool, ami segíthet ezt élhető keretek között tartani.

    (folyt. köv.)

  19. gabor.orosz
    2011. május 3. kedd - 13:23

    4.\“Most már nincs olyan, hogy másképp értelmezzék a box modellt, a margint, a paddinget és sok olyat, amitől az oldalak töröttek lettek. Annyi hozzáfűzni való van, hogy ott vannak a browser prefix-ek, amik lehetőséget adnak az újdonságok kipróbálására, kísérletezésre….”
    “Másképp értelmezik, ahogy nekik jó, mert ők a böngésző gyártók”
    Szerintem ez az érvelés néhány éve még ült volna, de ma már nem igaz. Senkire se igaz, aki a cloud computing-ra akarja építeni a jövőjét, és azokra a hagyományosan web-es óriásokra se, mint a Facebook, az Amazon, a Yahoo, a Twitter, Vimeo, Foursquare, Digg, LinkedIn, Wiki és sokan mások mellett a Google.

    (Bár a végére hagytam, de pont a Google a legnagyobb hal ebben az akváriumban. A teljes üzleti stratégiáját a cloud alapú appokra építi, Miszerint mindened náluk legyen elérhető, mindenhol, akár egy böngésző is elég ehhez. A strátégiájukat mi se bizonyítja jobban, hogy nagyon sok ismerősöm, már a böngészőn kívül csak a zene és video lejátszót nyitja meg.)

    Nekik igenis érdekük, hogy egy egységes, jól használható alkalmazás fejlesztési platformot tudjanak felmutatni. Fontos, hogy a fejlesztőket magukhoz édesgessék, és ez által a felhasználóknak egy még komolyabb web-es élményt nyújtsanak.

    Bár továbbra is lesz töredezettség, de az browserek új generációi között nincs már olyan jelentős szakadék, mint ahogy az az elmúlt években jellemző volt. Sőt, hogy ezt még tovább csökkentsék mind HTML5, mind a CSS3 modulok esetén prioritásokat határoztak meg, hogy milyen sorrendben kell az egyes új képességeket a böngészőkben implementálni. Másrészt az jelentős különbség, hogy eddig a szabványban nem szerepeltek a render részletei, most pedig már igen.

    Azt hiszem az MS-nek is érdeke ez, ha más nem, amiért Te is említetted. De nincs is sok választása, mivel most ő van vert helyzetben, és a többiek diktálnak.

    (folyt. köv.)

  20. reiteristvan
    2011. május 4. szerda - 09:56

    Na, látom valakinek grafomániája van 🙂

    Először Zolinak válaszolok, a többi is kapcsolódik majd ehhez:

    “Szögezzünk le egy dolgot, és szerintem itt most István nevében is beszélhetek talán (a következő egy mondatra nézve). TUDJUK, hogy a html5 a jövő, tudjuk, hogy a Silverlight gyakorlatilag lejött a webről.”

    Ez pontosan így van, lehet, hogy nem ez jött le a hozzászólásomból, de számomra is teljesen egyértelmű, hogy a html5 a jövő, ez kétségtelen. Igazából nem is nagyon tudom, hogy mi kellene ahhoz, hogy egyáltalán esély legyen rá, hogy megszabaduljunk a html-től (maximum ha a hardver is változik, de ez most lényegtelen).

    “Viszont, fordítsuk meg a dolgot, gondolkodjunk kicsit másképp, kezeljük az ügyfelet felnőttként, és magyarázzuk el neki, hogy mit fog kapni a pénzéért”

    Ez jól hangzik, de a probléma ott van, hogy a döntéshozók az esetek nagyon nagy többségében nem hozzáértők. Egy nem szakmabelinek pedig soha nem fogod tudni jól elmagyarázni ennek az iparnak az összefüggéseit, mert számukra ez “csak” technoblabla (ugyanígy pl. engem is összezavar ha a könyvelőm mond valamit mert én meg ahhoz nem értek). Itt most véletlenül sem arról beszélek, hogy az emberek ostobák lennének, ez egyszerűen tapasztalat kérdése.

    ” Azzal viszont vitakoznék, hogy nem lehet komoly GUI-t építeni, az a helyzet, hogy bizony lehet, és nem is akármilyeneket”

    Átfogalmazom: nem lehet könnyen, produktívan komoly GUI-t építeni. Amiket mutattál azok jól néznek ki, de inkább parasztvakítás mint valóban használható felület.
    A legnagyobb probléma akkor is az, ahogyan azt Zoli már leírta, hogy rettentően nehézzé válik a kollaboráció, egyáltalán nem egyszerű a designer/coder feladatainak összehangolása. Ezt pedig nagyrészt annak köszönhetjük, hogy a html-t – ismétlem magamat – nem erre találták ki. Te magad is leírtad, ez egy dokumentumleíró nyelv. Ugyan hozzábiggyesztették a javascriptet, de igazi integráció a kettő között nem tud kialakulni (erre a legjobb példa az egyes “vezérlők” kiválasztása: nem tudsz közvetlenül a a nevén hivatkozni, még a jquery alatt is kettőskeresztes, dollárjeles vacakolás van).

    (folyt. köv.)

  21. gabor.orosz
    2011. május 4. szerda - 12:02

    István, Zoli:
    “A legnagyobb probléma akkor is az, ahogyan azt Zoli már leírta, hogy rettentően nehézzé válik a kollaboráció, egyáltalán nem egyszerű a designer/coder feladatainak összehangolása. Ezt pedig nagyrészt annak köszönhetjük, hogy a html-t – ismétlem magamat – nem erre találták ki. Te magad is leírtad, ez egy dokumentumleíró nyelv. Ugyan hozzábiggyesztették a javascriptet, de igazi integráció a kettő között nem tud kialakulni (erre a legjobb példa az egyes “vezérlők” kiválasztása: nem tudsz közvetlenül a a nevén hivatkozni, még a jquery alatt is kettőskeresztes, dollárjeles vacakolás van).”

    Nézzük a problémát egy teljesen más szempontból. A frontend építésénél alapvetően a a Content-Presentation-Behavior (hívhatjuk MVC-nek, vagy annap sok más variánsának is) alapú felépítés a legelterjedtebb. Ezzel biztosíthatú egy olyan felépítés, amely az egyes részeket kellő mértékben elválasztja egymástól, és a rétegeket felfelé haladva cserélhetővé teszi, és nagyban elősegíti a kollaborációt is. Ha megnézed, akkor lényegében a modern web technológiák és a WPF \ SL is egy tőről fakad:
    Content – HTML5 XAML
    Presentation – CSS3 XAML (Style \ Theme)
    Behavior – JavaScript + jQuery C# + SL .NET (nem ugyanaz mint a nagy fw, de hasonló)

    Tekintsük az első két szintet, és máris látható, hogy nincs nagy, lényegi különbség. Úgy látom, amikor az MS-nél a WinForm utódját tervezték, első sorban a web-es világ technológiáiból inspirálódtak.

    Hangsúlyoznám, és ezt tévesen írtad le, a designerek hozzá se érnek a HTML-hez, nekik a CSS-en kell dolozniuk, már a CSS2.0 óta megoldható onnan minden. Ez egy lényeges szempont volt a tervezésnél, rengeteg a megjelenítéshez, és formázáshoz használt elem obsolate-be is került a HTML5 szabványban, és mindenhol azt javasolják, hogy a view-t CSS-ben old meg. Így teljesen elválasztható az a másik két rétegtől.

    Persze ez sem megy hozzáértés nélkül. El kell felejteni az in-line és az in-document style-okat, és külön file-ba küldeni a CSS-t. Végülis jobban belegondolva ugyanezt csinálta az SL is, hozzá nem értők ott is simán csinálnak spagettit, amit max karddal tudsz tagolni… de lényegében csak a szintaktika különbözik, az elv ugyanaz.

    (Itt látható a legjobb példa erre: http://www.csszengarden.com/
    A HTML minden design esetén ugyanaz, a CSS-t cserélik.)

    “A html5 tervezésének messze egyik legnagyobb hibája, hogy az animációkat nem oldották meg deklaratív módon… (mert 1. lenne hozzá rendes tooling, 2. Nem a fejlesztőre bízták volna, hogy optimális kódot írjon…)”

    Jó hírem van, Zoli. Így váljon valóra minden kívánságod, a CSS3 több közepes prioritású modulja is foglalkozik az animációk kérdésével, és mindezt teljesen deklaratívan oldja meg. Több böngésző már elkezdte ezen modulok implementálását a múlt év folyamán, de alapvetően a WebKit és Gecko motoros böngészők járnak elől. A következő témákról van szó:
    – CSS3 Transitions
    – CSS3 2D Transformation
    – CSS3 3D Transformation
    – CSS3 Animations

    (Bővebb info itt: http://www.w3.org/Style/CSS/current-work és http://www.css3.info/modules/)

    (Néhány példa a CSS3 animációk képességeire: http://www.1stwebdesigner.com/css/50-awesome-css3-animations/ Ajánlom többek között az AT-AT anim megtekintését, azt hiszem az oldal alján vannak, teljesen deklaratív keyframe animációkról van szó. Sajnos egyelőre csak WebKit-es böngészőkben, de rövidesen a többi is képes lesz megjeleníteni.)

    Ráadásul, a tooling támogatás se olyan kőkorszaki, ahogy azt már említettétek. Egyik hozzászólásomban már említettem jópár nagyon használható toolt, most pedig kibővíteném még egyel, ami a designerek-nek nagy segítségére lehet, ráadásul kifejezetten az animációkra gyúrtak a kedves készítők:
    http://www.sencha.com/products/animator/

    Igazából úgy érzem, hogy minden szerepkör megkaphatja a maga nyelvét, a tooljait, lehetőségeit, így a kollaboráció is magas szinten megvalósulhat. Illetve ha még láttok konkrét réseket, akkor továbbra is kíváncsi vagyok a meglátásaitokra.

  1. 2011. május 23. hétfő - 14:40

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: