html + arculat - külön

Üdv!

Van több html oldal (amit egy php generál, de ez lényegtelen). A kinézete siralmas jelenleg, vagyis igazából nincs is semmi. A kérdésem az lenne, hogy hogyan kellene kialakítanom a kódot ahhoz, hogy a html módosítása nélkül egy grafikusnak kiadva, Ő képes legyen egy szép arculatot ráhúzni (nyílván css- sel, meg képekkel, meg ki tudja még mivel)?

Ez így valószínűleg elég általános kérdés, de valami általánosabb választ is várok egyelőre, amin el tudok indulni, és talán konkrétabbat kérdezni.

Köszi a válaszokat!

Hozzászólások

Ha minden elemnek adsz egy id-t, akkor CSS-ben barmit meg lehet csinalni.

Tehát vegyünk egy nem túl népszerű, de table- s példát .

Ezzel így tud valamit kezdeni a designer, vagy esetleg a belső (

, ) elemeket is fel kellene címkézni. Tfh., azt szeretné, hogy az első oszlop kék színű legyen, a 2. és a 3. pedig zöld, és ami zöld, ott minden második sorban lévő kicsit erősebben zöld. Ez ebből megoldható? Hogyan? Mi lenne a css- ben, illetve mit kellene ezen a html- en változtatni hozzá?

Ez most egy elég egyszerű példa, de valahol mégis sok mindent lefed. Plussz lenne még, ha a fej sor más színű lehetne, de ahhoz a kódot is könnyen igazítom.

Köszi.

"az első oszlop kék színű legyen"
Ehhez minden sor első td elemére kell egy class.

"a 2. és a 3. pedig zöld,és ami zöld, ott minden második sorban lévő kicsit erősebben zöld."
Ehhez minden sorban a 2. és 3. td elemre kell egy külön class, plusz még minden második sor megfelelő celláira egy "mégzöldebb" class.

Tehát ez html módosítás nélkül nem oldható meg. Hacsak nem JS-el teszed a helyükre a megfeleő classokat.

Ha nem kell zebratable akkor ha a table normálisan van megírva akkor a fejlec nem td.
Egy normal tablenél én külön kezelem a fejlécet, láblécet(ha van) és a törzset.
Így egy egyszerű css-es megoldható a fejléc-törzs kezelés.
Persze zebratablenél már ez nem állja meg a helyét.

pch
--
http://www.buster.hu "A" számlázó
--

HTML módosítása nélkül aligha fogsz tudni új arculatot ráhúzni.

Miért? Nem pont az lenne a lényeg, hogy elkészítem a HTML- t, és a designer hozzáfaragja a css- t, meg a képeket, meg hasonlókat? Persze ahhoz úgy kell kialakítanom a html- t, hogy illeszteni tudja hozzá, és pont ennek a kialakításnak a mikéntjére vagyok kíváncsi.

kicsit el vagy tévedve.
A designer elkészíti a látványtervet, majd ez alapján kapsz egy szééép valamit.
A sitebuilder feladata az, hogy ebből a látványtervből kész html-t/css-t gyártson.
Te vagy az, akinek ez utóbbit (html+css) használnod kell.

Az, hogy te gyártasz valami html-t amit majd egy designer valahogy megformáz, nem az igazi. Nemmellesleg, ha ennyire nem vagy képben a feladatokkal illetve részfeladatokkal, kötve hiszem hogy olyan html-t fogsz gyártani, amire egyszerű lesz bármit is felhúzni.

minden php altal generalt html szoveget kulonbozo div id-ek es div classok koze raksz, amire ugy erzed, hogy osszetartozik, az mehet egybe, es akkor neki mar csak a stylesheet-tel lesz dolga tulajdonkeppen

Szerintem mindenképpen kell azért valami előzetes elképzelés, hogy mégis milyen struktúra szerint épüljön fel az oldal, akkor lehet ésszerűbben diveket és classokat adni a bekezdés- és szövegszintű tageknek stb.
--
Direp

Forditva kell megfogni a dolgot. Elmesz a grafikushoz dizajnerhez, megmondod, milyen dizajnt szeretnel, o megcsinalja neked a HTML kodot, te felszabdalod, es beilleszted.
Ezen a ponton viszont erdemes lehet elgondolkodni egy templating rendszer (smarty) hasznalatan is, rengeteget tud segiteni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

az elso kerdes az, hogy milyen html oldalak vannak ("Van több html oldal") - xhtml, html4, html5?

Bocsanat, de ez hol szamit egy dizajner-fejleszto interakcioban?

html4-nek is van doctype-ja, html5-nek is es xhtml-nek is, bar az utobbi kulonbozo itt nem reszletezendo okok miatt problemas.

Ertem en, hogy letezik ilyen problema hogy melyik valtozat, de ennek van barmi koze ahhoz, hogyan lehet egy kozos templating megoldast kialakitani ket eltero munkafolyamat tamogatasahoz?

igen van. a kerdezo altal feltett kerdesbol nyilvanvalova valik, hogy nem lat kozottuk kulonbseget, igy a meglevo kulonbsegekre erdemes meg a legelejen felhivni a figyelmet, mielott keszit egy quirks mode oldalt es majd nem erti miert nem ugy nez ki, ahogy az a rajzon volt.

ezen felul ahogy ramutattam, ott is jelentosege van, hogy mindharom leiro nyelvben mas-mas tagek leteznek, igy ha html5-ot hasznal, akkor a korabbi valaszokban ajanlott id jeloleseket pl. a header es a footer elemeknel (stb.) elhagyhatja, mig a masik kettoben nem.

igy tehat ez szerintem nem annyira problema, mint inkabb lehetoseg, es ha meg teljesen alap az a html oldal, akkor ezeket most erdemes atgondolni.

De, bocsanat, akkor mi tortenik?

TFH fogom magam, es egy HTML 4.01 Transitional doctype-pal ellatott oldalba belerakok egy <canvas> - mi fog tortenni?

Semmi, annak ellenere, hogy nem resze a 4.01 szavanynak a canvas, hisz egy joval kesobbi technologia, az osszes bongeszo amelyik tudja kezelni (IE9 es a vilag tobbi resze) le fogja renderelni.

Mondok rosszabbat: a HTML eddigi szabvanyai nem hataroztak meg kinezetet. Igy neked akkor is erdemes CSS-sel ujradefinialnod teljesen mondjuk a <h1> -et, ha az resze.

Mi tortenik, ha egy HTML 4-es oldalba bekerul - mondjuk valamilyen CMS funkcionalitason keresztul - egy lezart <br/> tag? Valoszinuleg semmi.

Es ha egy XHTML oldalban lefelejtem a zarast egy <p> tagrol?

Egyetlen egy dolog tortenhet, hogy a Trident (IE6-8) rendering engine atvalt ugynevezett quirks modba, es szejjelrepul az oldal. Ez az egyetlen gyakorlati kovetkezmenye ha rosszul hasznalom a semat.

Az XHTML-rol paran mar elmondtak a velemenyuket, tobbek kozott az A List Aparts-on is, elmondtak a Safari / WebKit blogjan is, sajna azt a cikket, amire evekig hivatkoztunk hogy miert egy hatalmas baromsag az XHTML mint elgondolas, nem talalom epp, a google ugyanis szereti a 2000-es evek elso felenek weblapjait "elfelejteni".

A HTML szabvanyverzio az szerintem szinte kizarolag vallasi kerdes, a gyakorlati kovetkezmenyei infidezimalisak, es alig van olyan, amit egy automatikus tool - pl. htmltidy - ne tudna javitani.

De hajra, varom a velemenyedet arrol, hogy mi az, ami miatt mar az elejen ezzel kell foglalkozni, milyen architektura-szintu implikacioi vannak?

Es felre ne erts: nincs semmi bajom azzal, ha elmeleti tisztasagot kovetelunk ki. De ha a facebook es a google is siman megcsinalja azt, hogy html5-ot szolgal ki neked, ugy, hogy emberek meg hasznalnak IE6-ot, akkor azt gondolom, a vilagon van fontosabb problema is.

Annyira jó, hogy ennyire tök mindegy hogy mit ír a kódjába HTMLPistike, mert így oldalbetöltési/renderelési sebességben ugyanott tartunk a 25/8 MBit esetén, mint anno ISDN-en 8-10 évvel ezelőtt.

Komolyan, a technológia fejlődése nem azért van, hogy beleszarhassunk az optimalizációba, mert "úgyis van elég sávszél és processzoridő, memóriáról nem is beszélve"...

Hogy tartanal mar ott renderelesi sebessegben, a Google szerinted HTML5-ot hasznalna a kevesbe liberalis barmi mas helyett ha renderelesi sebesseget ez lenyegesen befolyasolna?

A renderelesi sebesseget a fa melysege, a selectorok specifikussaga, az eroforrasok sorrendje es merete, es a szukseges scriptek befolyasoljak, nem pedig az, hogy valid-e a HTML-ed.

es keress valami regi oldalt, mittom, extra.hu vagy valami, meg korlatozd le tuzfalon 64 kbps-re a netet egy korabeli (1 magos, 1-2 GHz) gepnek, nezd meg mennyi ido alatt tolt be.

A szukseges hatarertekek valtozatlanok:
0.1 mp a "szemvillanas alatt"
0.2 mp alatt akciovalasz kell
1 mp alatt be kell fejezni nem fizikailag idoigenyes (pl. oldalbetoltes) feladatokat.

Ezt ma mar egy Google vagy egy Fb tudja hozni, 10 eve nem tudta.

Lehet, hogy csak nálam nem kóser valami, de még a hup.hu, ami nincs teleJS-elve, nincs tele képekkel, viszonylag reszponzív szerveren ül, na ez az oldal se hoz kitűnő felhaszálói élményt. Pedig XXI. század van már!

Google, Facebook, hasonló baromságokról ne is beszéljünk. A legtöbbet ezeknek a rohadékoknak a scriptjeire kell várni általában, mire betöltődnek.

Azt meg nem nehéz belátni, hogy az a render-engine, ami csak strictet kezel és csak arra számít, az gyorsabban renderel, mint amelyiknek még el is kell döntenie, hogy ez most tényleg megfelel-e a doctypejának, vagy se.

Nalad lesz valami, mert nalam a hup (pedig az en gepem, barki megmondja aki mar latott vele dolgozni, nem a leggyorsabb) reakcioidon (100 milisec)-en belul hozta pl. ezt a formot (UPC, Budapest, 2.4 GHz Core2Duo, Apple Macbook Pro Early 2008, Snow Leopard 10.6.8, Safari) - mindekozben megy egy csomo app, tobbek kozt egy photoshop.

Google is hozta mindig ezt a sebesseget, ezert nagyon sokaig alig voltak benne scriptek.

Nincs olyan render-engine ami kizarolag strictet kezel. Egy volt, bebukott, mert az XHTML-bol nem lehet kezelni a strictet ertelmesen, es mindenki futyult ra, a felhasznalo weboldalakat akar nezegetni, nem szabvanykoveto XML fajlokat es XML not valid hibakat felvaltva.

De mondok neked jobbat: A browser ciklusa a kovetkezo:
1) Uj HTML kod parse-olasara kerik -> egy sima libsgml parser lefut rajt, 0.0001 ms alatt, eredmeny: DOMElement vagy DOMDocument. (parse)
2) Arra kerik, illessze be ezt egy faba -> famuveletek, hash-ek, mittom (DOM)
3) Arra kerik, ezt rendezze el sikba (reflow)
4) A sikba elrendezett oldalt jelenitse meg a kepernyon (repaint)

Ezek kozul az 1-es pont nagysagrendekkel kevesebb idobe (nanosecekbe, soha se tobb,mint 1-2 milisecbe) kerul, mint a kovetkezo pontok barmelyike, a beillesztes mar eleve 10-20 msec-et elvehet, a reflow akar 100-at is, a kirajzolas rendszerfuggo.

Lehet erre optimalizalni, de en mondjuk inkabb a reflow esemenyek szamat minimalizalnam, keresnek minel hatekonyabb paint eljarasokat (OpenGL alapu megjelenites, mittom), hatekony adatstrukturat a DOM tarolasara (bar aze' ilyen is szerencsere van) bongeszooldalon, kliensoldalon meg a minel egyszerubb fastruktura, minel kevesebb reflow, minel jobban hintelt (pl. szia, ez itt egy video) mennek, es erre is teszik.

"Es felre ne erts: nincs semmi bajom azzal, ha elmeleti tisztasagot kovetelunk ki."

hat pedig nagyon ugy viselkedsz... de mivel ezzel a hozzaallassal csak magadat minosited, a temat itt lezartnak tekintem, utolso megjegyzeskent annyi, hogy probald meg a php kodot is ilyen szabadon kezelni, es php5-ben megjelent fuggvenyeket hasznalni egy php4-et futtato szerveren, aztan majd magyarazd meg, hogy elvileg ennek nem szabadna semmilyen hibat okoznia, hiszen nem szukseges, hogy egy kod valid legyen.

az pedig, hogy a bongeszok a rosszul megirt oldalakat is megjelenitik, nem azt jelenti, hogy igenytelennek kell vagy szabad lenni, csupan azt, hogy a bongeszok fejlesztoi felismertek annak tenyet, hogy sok igenytelen ugynevezett webprogramozo van. szoval ezzel en nem ervelnek a helyedben - olyan mintha azt mondanad, hogy tuleltem, amikor atmentem a piroson, vagyis a piroson jo dolog atmenni...

Én például azt mondom, hogy pont hogy baj a „szabványkövetés megkövetelése”. Persze, jó dolog a szabványkövetés, de egy weblap nem valami misztikus valami, aminek szigorú szabályok szerint kell lennie.
Hanem egy nyomorult tartalom megjelenítő vacak. Vagyis, nagyon nem érdekel, hogy 0,5mp-el később tölt be, ha a rajta levő tartalom fontos a számomra. Az meg, hogy pazarolja az erőforrást. Amíg a kliens gépét pazarolja, inkább nem ijedek meg a gigabájtnyi memória, és a kukoricacsőnyi magos processzorok idejében.
És még mindig nem azt írom, hogy _ne törekedjünk_ a szabványkövetésre, hanem azt, hogy _ne tulajdonítsunk több jelentőséget a html szabványoknak, mint amennyire szükséges_.
(És a példád a php dologról meg. A html _nem_ programozás, a php meg, minden nyűgével együtt is, az. Ezeket össze hasonlítani olyan, mintha a gyerekrajzot hasonlítanánk a műszaki rajzhoz, abból a megfontolásból, hogy mindkettőnek köze van a rajzhoz. )
És mindez persze csak magánvélemény, magánszemélyként. Ha megfizetnek, természetesen fanatikus html szabványkövető leszek. Ezt csak a "még jó, hogy nem velem/nekem dolgozol" beszólások elkerülése miatt írom. :) <- Az ott egy smile. Arra vonatkozik, hogy a megjegyzés írója megpróbálja elkerülni, hogy halálosan komolyan vegyék azt, amit ír.

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

Nem, én windowst használok, és azt nem zavarja, hogy ~15 program van nyitva, jellemzően napok óta.
És nem hinném, hogy egy core2 és 3gb memória olyan nagy dolog lenne. Szerintem már telefon van erősebb, mint ez a gép. Vagyis, tényleg nem értem a problémát. Persze, lehet misztifikálni, de akkor fejlesszünk 640x480-ra, mert olyan felbontás is létezhet.
Vagyis, a probléma valós, de nem lényeges annyira, hogy megérje a ráfordított erőforrásokat.
(Szigoruan magánvélemény, még mindig. A fent leirt dolgok továbbra is vonatkoznak rá.)

És a felhasználókra amúgy tényleg jellemző a „egyszerre egy programot futtatok a gépen” dolog. Mi több, egyre inkább ebbe az irányba megy a világ, lásd: tabetek, amikben minden teljes képernyőn fut, meg a windows8.
A programot (weblapot) a felhasználóknak kell írni. A dokumentációt kell a szakmabelieknek. Ez az én véleményem.

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

Teljesen igazad van, csak úgy tűnt, hogy általánosítasz, és személyeskedsz. Mintha az, aki másképpen gondolja/csinálja, kevésbé lenne értékes, mint mondjuk te. Ez pedig legalább is furcsa.
Gratulálok, írtál egy végtelen ciklust. Szegény elpazarolt erőforrások. :)

A jelenlegi allaspont a kulfoldi szakmaban az, hogy ilyen nincs. Az idealisztikus vilag, hogy majd mindent felcimkezunk classokkal meg id-kel, es semminek nem kell wrapperdiv, meg nem kell fix sorrend sehova meg tudomisen, ez egeszen lealdozoban van.

Arrol cikkeznek nagy erokkel, hogy a dizajnerek ertsek a HTML-t, sot, dizajnoljanak rogton HTML-ben (hozhatnank a Smashing Magazine nevu dizajnerblog vonatkozo cikkeit, vagy a facebook fo dizajnerenek vonatkozo interjujat.

A szetvalaszthatosag modjairol amugy a smashingen legutobb a Yahoo! dizajnere cikkezett itt.

O is megemliti, itt is erdemes hozni a Yandex (orosz google) BEM nevu frameworkjet, metodologiajat, hivjuk, ahogy akarjuk, kod is van benne, meg hogycsinald is.

Amit mindenkepp szoktunk mondani, hogy class-okat meg id-ket hasznalj, ez legyen a kozos tajekozodasi pont. Ez a facebooknal allitolag katasztrofaba torkollott, ez hajtja a Javelin szigoru szetvalasztasi filozofiajat, class helyett "sigil"-ekkel.

Arrol, hogy hogyan kell egy template-et programozasilag kialakitani, TJ Parr ertekezett a legjobban, illetve egyes frameworkok hasznaljak az MVVM architektura elveit nezetek generalasara.

Hogy mi a megoldas? Nem tudom. En azt szoktam mondani, a legjobb, ha az ember megtanul dizajnolni, amihez jo alapokat magyarul a Tervezz Batran! (eredeti cimen The Non-Designer's Design Book) tud nyujtani, aztan ha mar belejossz, akkor lehet nezni ilyen mindenfele dizajnkatalogusokat (web designer's idea book, smashing idea book - nem kell magyarul lennie, egy rakas screenshotrol beszelunk)

Akkor nincs kinek atadni, nincs ebbol para.

persze a szeperzek a kockakbol nem mindig jon ki...

konyorgom, ne keverjuk a sitebuildert/designert/programozot. A designer nekem csak ne tanuljon html-t, mert akkor elkezd sablonosan gondolkodni (jajj, ezt nehez megcsinalni) es egeszen mas munkak szuletnek ugy. A sitebuilder meg azert van, hogy a designer altal kitalalt (akar baromsagot is) html-css formaba ontse es azt ertse a legtobb bongeszo is.
Mind a ketto egy-egy szakterulet, egy agysebesz se akarjon nekem autoszerelo muhelyt nyitni (hacsak nem befektetes es nem o dolgozik benne)

Valamilyen szinten muszaj ertenie a HTML-hez, hogy ne jojjon megvalosithatatlan dolgokkal. Tisztaban kell lennie azzal, hogy nem grafikai munkat vegez, es az oldalt - hacsak lehet - nem kepekbol akarjak osszerakni, hanem HTML-ben, vagyis tisztaban kell lennie a technologia korlataival.

Hogy dolgozzon is HTML-be... nos, ez egy erdekes kerdes. A legtobb hazai cegnel valoszinuleg azt mondanak, hogy igen, mert akkor megsporolnak plusz egy embert (sitebuilder, ugye), mert a munka dandarjat a designer + programozo paros lemeccseli egymassal.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Oke, akkor elmondom mas szoval, szoval vannak olyan dolgok, amelyek ugyan megvalosithatoak, de tul sok eroforrast esznek, vagy csak siman optimalisan nem valosithatoak meg. Mivel a te definiciod szerint ehhez a designernek nem kell ertenie, igy ezt figyelembe se tudja venni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ertem, hogy papiron ne keverjuk, csak ha nem ertunk egymas meloihoz, az legalabb olyan fos lesz,mintha egymas helyett csinalnank, nem?

Mondok jobbat: nekem most epp kene egy dizajner (nem a pelda kedveert, tenyleg), de fizetni nem tudok. Kit kerhetnek meg? Az orszagba van kis tulzassal harom-negy dizajner akiben megbizom, es hat ennel egy nagysagrenddel tobbet ismerek minimum, csak olyan melokat lattam toluk, hogy sirvafakadok.

Volt hogy egy konyvben nem volt pl. oldalszamozas, mert az amugy print dizajner az nem tett bele. Volt amelyik megijedt - nem a html-tol, hanem - az adobe indesigntol meg az omnigraffle-tol.

Az egyik ismert cegnel - telefonokat gyart - a velem dolgozo dizajner konkretan szinvak volt, nem viccelek, nem beszolas, hanem orvosi eset - a kartografusoknak feltunt, es poenbol elkezdtek neki szinvaksagi proban bukott terkepeket mutogatni. Masnap jon hozzam, "Te, az X szinvak" "Tudom, ezt irtam neked a legutobbi dizajnjarol" "Nem, tenyleg, nem tudja megkulonboztetni a keket a pirostol" "Ez evekre visszamenoleg mindent megmagyaraz". A csavo vizualis dizajner, nem UX, mielott barki ebbe kotne bele.

Mit tudnek csinalni? Leveszem a polcrol a Bergstromm-konyvet, szarrakategorizalok 100 kepet gyakorlasbol, elkezdek kitalalt cegeknek logokat tervezni, leirom betutipusokrol hogy milyen erzeseket valt ki belolem, visszaellenorzom, hogy a dizajnkonyvek vajon ezt gondoljak-e rola, elkezdek korszakokat tanulni, megprobalom leirni egy dizajn elemeit, leklonozok egy dizajnt, aztan megprobalok ugyanolyan stilusban valami mast, megmutatom embereknek, megkerdezem, mit gondolnak rola, felirom, jol vittem-e at az erzeseket, jol hasznalom az elemeket, stb...

Vensegemre ugylatszik, meg kell tanulnom a vizualis dizajn szakmat is, mint ahogy a programozasrol is azt gondoltam, hogy az nekem csak arra kell majd, hogy a kis code mokeykat felugyeljem, oszt beutott az agile, az UX-rol is azt hittem, vannak emberek, akik ertenek hozza (nincsenek, ill. qrva kevesen), latod, ez igy megy, magad uram, ha szolgad nincsen.

Ugyanakkor azt latom, hogy ami kikerul kezekbol, az vallalhatatlan, vagy pl. mert leprogramozhatatlan (HTML4-ben nehez volt alulrol felfele, mmint geometriailag a kepernyo aljarol felfele szamitott) dolgokat epiteni, footer-t meg csakcsak, de belso elemet...) vagy azert mert van benne egy 2 megas b.szottreszletes kep hatternek,ami sehol nem akar ismetlodni, es a grafikus kepernyojenek szeleig tartott (szelesebb kepernyonel mivan?), esetleg atmeretezhetetlen (az ottani Lorem Ipsumra pont jo volt) vagy mondjuk egyszeru elveket, mint pl. hogy folyoszovegnek megfelelo kontraszt kell, nem sikerult betartani.

De latok vallalhatatlant programozasban is, nem kell mindent az iparmuveszekre kenni, es nyilvan nem fogok annyira erteni hozza, mint az informatikahoz, hisz valamikor fiatalabb koromban eveken keresztul benn ultem a lagymanyoson mindenfele termekbe ezt hallgatva.

a tehetségtelen ért mindenhez, a jó, csak ahhoz amihez, de azt viszont jól tudja. A párom pont grafikus (és csak webdesign-t gyárt), print design-al nem foglalkozik (pedig az indesign-tol és a corel-tol sem fel), csak egyszeruen nem az az o terulete es sitebuildel sem foglalkozik. Mivel magyarorszagon pont ilyen univerzalis fost keresnek mindenhova, univerzalis fosok vannak mindenutt (tisztelet a kivetelnek), o viszont jol eladja magat kulfoldon es szep designt gyart.

"Ugyanakkor azt latom, hogy ami kikerul kezekbol, az vallalhatatlan, vagy pl. mert leprogramozhatatlan (HTML4-ben nehez volt alulrol felfele, mmint geometriailag a kepernyo aljarol felfele szamitott) dolgokat epiteni, footer-t meg csakcsak, de belso elemet...) vagy azert mert van benne egy 2 megas b.szottreszletes kep hatternek,ami sehol nem akar ismetlodni, es a grafikus kepernyojenek szeleig tartott (szelesebb kepernyonel mivan?), esetleg atmeretezhetetlen (az ottani Lorem Ipsumra pont jo volt) vagy mondjuk egyszeru elveket, mint pl. hogy folyoszovegnek megfelelo kontraszt kell, nem sikerult betartani."

O egy tehetsegtelen webgrafikus, az hogy webre keszit valaki valamit es hogy html-t gyart, nem fugg ossze. A tehetsegtelen tehetsegtelen marad. A webdesign-ban vannak szabalyok, azokat kell tartani, a tobbit meg megoldja egy jo sitebuilder

A tehetségtelen ért mindenhez, (vagyis a webgrafikától a űrutazásig, belefoglalva, de nem kizárólagosan a púpos bálnák szaporodási énekét – ez alatt az van értve, hogy mindenben szakértőnek gondolja magát, a benne elért tudásszinttől függetlenül) a jó, csak ahhoz amihez, de azt viszont jól tudja. (vagyis mint például Leonardo da Vinci, aki minden kétséget kizárólag talán a legsokoldalúbb, és legtehetségesebb ember volt, mégsem tudok róla, hogy foglalkozott volna a lazacok vonulásával. De amibe belekezdett, azt tökéletességig vitte.)
Most vagy tényleg nem ezt jelenti a fent irt mondat, vagy alapvető szövegértési problémát látok. Tekintetbe véve a kettőnk közötti haszon, és elért pozíció különbséget, őszintén remélem, hogy én értem rosszul.
Mert a másik esetben kedvem lenne sírva bevonulni egy sarokba. De aztán megvidámodva kijönni, hogy legalább bizonyítva van, hogy igaz az, hogy nem kell még az érettségi szintet elérni ahhoz, hogy sikeres legyen az ember. De ezt nem fogom elárulni a gyerekeimnek, mert akkor abbahagyják az iskolát valahol a 6. osztálynál, és azt kudarcként élném meg.

Meggyőződésem, hogy bármilyen szakmában elmélyed az ember, ha attól eltérő tudományban/szakmában is szerez némi jártasságot ponyvaismereteket, akkor a saját szakterületén kifinomultabb munkát fog végezni és tudása értékesebb lesz, önbecsülése nőni fog.

pl.:
- Nem tudok elképzelni jó grafikust anélkül, hogy az illető ne tudjon minőségi fényképeket készíteni.
- Nem tudok elképzelni jó marketingest, szociológia és pszichológiai ismeretek nélkül.
- Nem tudok elképzelni jó közgazdászt cégvezetőnek, a motiváció és a retorika ismerete nélkül.

ps.: Saját magam jobb példa lennék, csak nem akartam magammal példálózni. :)

Nem tudok elképzelni oregont flame és arcoskodás nélkül.
Te vagy az egyetlen, aki idejött a topicba és beleköt egy mondatba (mindenki más segítőszándékkal érkezett), amit az összes többi megértett. Te nem vagy más, mint egy troll.

Példálózz csak magaddal, leszarom. Van pár olyan ember aki a hosszú évek alatt kiverte nálam a biztosítékot, ebből az egyik Te vagy. Semmilyen építőjellegü, vagy témába vágó hozzászólást nem is várok tőled, mert vérbeli Troll lévén, te csak ennyire vagy képes.

ui.: Hogy ne csak rajtad fröcsögjek.
"- Nem tudok elképzelni jó grafikust anélkül, hogy az illető ne tudjon minőségi fényképeket készíteni."
Ha meg már minőségi fotókat készít, legyen legalább 10 év referenciája ilyen téren. Ha már van referenciája, legyen legalább 3 év filmezésben eltöltött szakmai tapasztalata. Ha már filmezett, akkor legyen legalább egy nagysikerű mozifilm aminél segédkezett. Ha már segédkezett, legyen profi animátor és pixel sebész (CG artist). Sorolhatnám, de minek?

Innen látszik, hogy te univerzális emberekre vágysz, akik a saját szakmai fejlődési idejüket minden egyéb másra fordítják (rosszabb esetben ne legyen életük). Szerintem húzz el egy sötét sarokba és gondolkozz el az életeden.

Ez nem egyedi vélemény sajnos, csak én a fordítottjával szoktam találkozni fényképészként: ha a Photoshopot/Gimpet ismered, akkor már nem nagy dolog logót/szórólapot/névjegykártyát tervezni és kivitelezni, gondolják sokan. Sőt, videózz és szerkeszd azt is, mert ugyebár az is kép, csak kicsit mozog.
--
Direp

Én pl agyonvágtam a fotósomat annó, mert megpróbálta retusálni a fotókat.
Gyönyörűen fotózik (sőt, elismert és neves fotós), a photoshophoz is ért mert rákényszerűl az ember ebben a szakmában, de nem megy neki:)
A retusálás megint egy külön művészet már lassan (és nem, nem arra gondolok retusálás alatt hogy beállította a színeket és a kontrasztot, konkrétan egy háttér elemet akart kiszedni)

Sokan sajnos a szín-kontraszt stb. korrekciót sem tudják megfelelően megoldani, régen ugye megcsinálta azt is a labor. Informatikai területen sem könnyebb amúgy meghúzni egy határt, hogy ehhez még értek, ahhoz viszont már nem.. az idő és a gyakorlat azért segít a döntésben, ahogy a példád is rávilágított. :)
--
Direp

Ez az, amit en is ki akarok hangsulyozni. Bar szerintem nem baj, ha nem ijed meg, ha valahol lat egy HTML taget, arra mindenkepp szukseg van, hogy ertse, mit csinal, tudja, mi hajtja az oldalt. Szerintem sima egyszeru szabalykonyvvel ezt nehez leirni, betartatni meg nehezebb. Ha viszont erti, hogy mit csinal, akkor mindez termeszetes lesz.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A designernek template-t kell adni, tanulja meg használni (vagy haljon éhen).

Én pont most bírtam rá egy grafikust a jinja2 használatára, meg némi alapszintű programozásra szóval nem lehetetlen.

javaslataim:

TL;DR - http://bootswatch.com/

- kérdezd meg a designer-t, akivel dolgozni akarsz - budget függő ugyanis, hogy mit tud, mit hajlandó megtanulni egy designer, és egy sitebuilder

- döntsd el, hogy cél-e a vérprofi, továbbfejlesztésnél "szakmai mércével nézve" kompatibilis design, lásd Mcsiv által magyarázott "designer nem sitebuilder" elgondolás

- próbálj ki pár template rendszert, css framework-öt, amit javaslok: http://twitter.github.com/bootstrap - gyakorlatilag pont webapp-ok (jól értem, hogy valami ilyenre kell neked, nem egy CMS-hez, vagy egyéb) frontendjének könnyű és gyors kialakításra való, ha standard html kódot írsz, csak pár percnyi kiegészítés kell, hogy szép legyen (sablonos, tehát bootstrap default, de szép, nem vérkomolytalan)

- sablonkezelésben, ha nincs időd implementálni egy smarty-t, már a designer annak is nagyon tud örülni, ha legalább a header statikus részei, akár a menüsor, footer, ... statikus html fájlokba ki van mentve neki, ezt te is két perc alatt beforgatod akár csak include-okkal

- a fenti hozzászólásokat válaszd szét komolyság alapján, én úgy érzem az írásodból, hogy még csak próba jelleggel gondolkozol ezen, nem üzletileg létszükséglet neked a "skin-ezhető", akár percek alatt átalakítható kód, csak jó lenne már a készítéskor, 5-10 perc plusz ráfordítással designer barát kódot készíteni. erre jók a framework-ök, ha nincs sok igényed.

- http://bootswatch.com/ - bootstrap-hez (biztos más css framework-ökhöz is, de én ezt használom) vannak skin-ek, gyakorlatilag egy css fájl kicserélésével, esélyes hogy bármilyen képfájl hozzáadása nélkül (except céges, szoftver logó, egyedi elemek) pofás kinézeteket kaphatsz.

- megjegyzés: ha a szoftvered UI kialakításánál nem működött közre senki, aki ergonómiai alapokhoz értene, gondold meg a komoly újragondolást, hihetetlen plusz értéket jelen egy optimizált, vagy csak jól átgondolt rendszer, átlátható folyamatokkal a UI mindkét oldaláról

Szerintem dinamikus oldalak esetén a megfelelő megközelítés az, ha az alkalmazás logikát eleve elválasztod a megjelenéstől.
Ez azt jelenti, hogy az alkalmazás logika kódjában semmi olyasminek nem szabad lennie, ami a megjelenéssel és a megjelenített tartalommal foglakozik, hanem csak a kívánt adatok összegyűjtésére, kezelésére koncentrál.
Erre legjobb megoldás a sablon rendszerek bevezetése, amely lehetővé teszi, hogy a programozó, a grafikus és a sitebuilder is azzal foglalkozzon, amihez ért. A programozó foglakozhat az alkalmazás logikával, a sitebuilder elkészíti az alkalmazás logika számára a sablonokat, amely "nyers" anyagát szállítja a grafikus/designer. A kész alkalmazás logikának a sablonok alapján kell előállítania a végleges html-t.
Sajnos php-hoz nem értek. Java alatt a problémára kiválló megoldás az Apache Wicket sablon rendszer, amelyhez hasonló szerintem biztos van php alá is.
Legroszabb esetben lehet írni is egyet. Nekem is volt olyan projektem, ahol cgi-t kellett írni úgy. hogy az előre definiált tartalom megjelenése, felépítése szabadon változtatható kellett, hogy legyen. Végül csináltam egy html-be ágyazható primitív sablon nyelvet, amelyet a c-ben írt cgi beolvasott, feldolgozott, aztán kitolta a legenerált végleges html oldalt.
A html + css részéhez kis bevezetőnek ajánlom a http://www.standardsmode.hu/ leírását. Nem megy mélységekbe, de egy kicsit azért megmutatja, hogy hogyan is működik ez az egész.

Zavard össze a világot: mosolyogj hétfőn.