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

Morzel

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

http://html5test.com/

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. 🙂

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. 🙂

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ó)

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.

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.)

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.)

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.)

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.