friizu.com

  • friizuurikas 11 a

    blogi suri ära, pole aega kirjutada, vaba hetk tekkis, panin sellise eneseupitamise lehe püsti (hetkel tööd juurde ei otsi, lihtsalt leht, et oleks leht).

    friizu.com

    Aga pihta võib ikka anda, selle lehe sisu hetkel tuleb fb ja tw feed + paar saatilist lehte. Kurb et portfoliot ei ole avalikult, aga sellega on nagu on, 101 +1 inimeselt peaks luba küsima, et avalikult välja panna ...

    22. mai 2013 - 22:48:15 · Otselink

  • Maart 11 a

    tekst on tahtlikult väike ? Muidu cool ja pane portfoliot ka ülesse :)

    23. mai 2013 - 00:51:38 · Otselink

    3

    • Portfoliot oleks küll huvi vaadata.

    • panin midagi, need liveveebid millel suuremas osas minu käsi küljes olnud, tegelik portfell võtab ikkagi aega ja nuputamist veel.

    Loe kõiki

  • aivopaas 11 a

    Üldpilt vinge.

    Kui keskmine (lõusta) ring muutub värviliseks, võiks äkki ka ikoonid värviliseks minna? Võib-olla oleks ka värvilseksm uutumisel fade parem kui praegune laksust - natuke häirib, kuna kõik muu feidib.

    Useless links, "mysocial" lahku?

    Sekst on jah kole väike. Kohatäide või lugemiseks ikka mõeldud?

    Sisuosa whitespace (alt ja ülevalt) vajaks mõnes kohas korrigeerimist (portfell, kontakt ja äkki ka home, timeline)

    23. mai 2013 - 09:18:44 · Otselink

    1

    • t2nud asjaliku tagasiside eest, fixisin mõned pisivead ja keerasin kirja veel tiba suuremaks

    Loe kõiki

  • rp 11 a

    architect

    23. mai 2013 - 10:43:53 · Otselink

  • Kustutatud 11 a

    ma ei vingu ka aga kysim2rk selle kohta et html5 expert aga koodist ma ei leia yhtegi html5 semantilist tag'i. pluss inline stiilid no maitea. id'sid css hookina mitte kasutada on rohkem vist mu enda eelistus.

    23. mai 2013 - 12:42:02 · Otselink

    8

    • ma pean siiski enda kaitseks ütlema, et algne kood oli täiesti valideeruv xHtml, nüüd on lihtsalt valideeruv htm5.

    • aga hea et koodi kallal ka vahest nokitakse, motiveerib parandama :)

    Loe kõiki

  • friizuurikas 11 a

    Njah, rääkides ID kasutamisest css hookidena, selle üle on palju lahinguid peetud. Seal on plusse ja miinuseid, aga wuzz'iga ei saa kuidagi nõus olla et ID on ainult js jaoks. Senikaua kuni ID kasutatakse unikaalsetele html elementidele on kõik korras ja standartne. Rääkides sellest, et ID ja class peaks ühele elemendile topelt panema (esimene js ja teine css jaoks), siis miks, me teeme koodi lihtsalt pikemaks ja märgiks ka ära, et tegelikult teeb ID css hookina kasutamise lehe renderduse kiiremaks (jutt käib küll millisekunditest).

    Ühesõnaga, eks kõik sõltub konkreetsest lehest ja koodi kribaja eelistusest, aga mina pigem ei ole nõus, et ID ei võiks css kasutada, tegelikult olen ma kuulnud paari "vabandust", esimene, et kui ID on ainult js jaoks, siis on koodi lihtsam lugeda (jääb mulle veidi segaseks), teine argument, et classe saab topelt kasutada ja ID mitte on õige, samas ID anname unikaalsele elemendile, mis nagunii on oma stiiliga ja kui vaja sama stiili, saab lihtsalt kirjutada #header, #footer {...} - mis on tegelikult handy, sest kui meil vaja footerit muuta, saame ilma html'i näppimata css failis uue stiili anda footerile, oleks meil html mõlemal blokil sama class, siis me seda ei saaks. Kolmas põhjendus ID kasutamise vastu on see, et ID kirjutab classi üle, nii see on ja seda teades saab seda pigem enda jaoks ära kasutada, probleeme tekitab see siis kui css ise on jaburalt kirjutatud. Lisaks saame dokumendis ID vajatusel ka ankruna kasutada, mis on samuti boonus.

    Aga on muidugi ka mõned kindlad juhud kus ID ei tohiks kasutada. Näiteks kui teeme widget'i mis läheb mõnele teisele lehele (sellisel juhul me ei saa ID unikaalsust kontrollida), aga see pole enam css'iga seotud.

    See on muidugi puhtalt minu arvamus, sellele võib vabalt vastu vaielda ja olen valmis oma vaadet asjale revideerima, kui keegi toob välja mõne tugeva argumendi ID css'is kasutamise vastu.

    24. mai 2013 - 11:00:06 · Otselink

  • wuzz 11 a

    Kui sa algusest lõpuni asja ise valmis kirjutad siis reaalsuses vahet pole. Kui aga progejad koodi üle võtavad siis nad 99% tõenäosusega tahavad kasutada enda namespacet, mis tähendab, et tahetakse su ID'd ümber nimetada misiganes frameworkist lähtuvaks juraks. Kuna mitut sama nimega ID'd olla ei tohi ja ühel elemendil ei tohi olla ka mitut ID'd siis on hädad kiired tulema. Kui koodi korrektselt kirjutada siis ilmselt ei ole üldse ID'sid vaja ning peaks kõik saama semantiliste tag'idega lahendatud.

    CSS'is ID kahjuks räägib ka see, et teinekord planeeritud unikaalsed elemendid saavad omale uue rolli ning mingitel tingimustel on sama elementi vaja lehel mitu korda mitmes eri kontekstis kasutada - sama layout kuid eri sisu. See aga tähendaks CSS'i muudatusi ja committi kogu projekti. Classina seda muret ei tekiks. Kui nüüd öelda et näe header ja footer ju ei ole mitu korda siis nemad peaksid olema üldse semantilised tag'id ilma classi ja ID'ta.

    Teooria samas on ilus, praktikas kasutatakse kõike segamini.

    # vs . prioriteetide puhul muidugi palju õnne !important'iga overridemise puhul kui algset stiilipakki hakkavad täiendama responsive seisud, kliendi segmendi skinnid ning veel WCAG nõuetest tulenevad kontrastivahetused :) Ma enda karjääri puhul olen kasutanud mõlemat lähenemist ja viimasel ajal kaldun 100% classipõhise CSSi poole, hoiab oluliselt aega kokku progejatega vaidlemise pealt.

    24. mai 2013 - 11:14:09 · Otselink

    3

    • Header, footer jms semantilised elemendid pole kindlasti unikaalsena mõeldud. Need on konkreetse konteksti headerid ja footerid.

    • Elementide selectorina kasutamine samuti libedale teele minek. Mõistlik kasutada classe, mida saad suvalise elemendi külge pookida hiljem.

    Loe kõiki

  • friizuurikas 11 a

    Eks ta nii kipub olema jap, et teooria erineb praktikast :( Muidu üldjoontes nõus ja loomulikult eks html/css võiks lähtuda juba eos frameworkist, mida plaanitakse kasutada. header - footer olid lihtsalt näited, pigem siis unikaalse disainiga block element millele semantiline tag puudub. Aga see ei ole küll tore kui progejad hakkavad id'sid suvalt ringi nimetama või külge pookima.

    24. mai 2013 - 11:52:41 · Otselink

  • wuzz 11 a

    Loomulikult ei ole tore kuid kohati võivad lihtsalt ID'd kusagil mujal juba kasutusel olla, eriti kui kasutatakse väga geneerilisi nimesid. Ma juba kohati mõtlen üldse kirjeldavatest nimedest loobuda, sest 50% juhtudel elemendi olemus muutub ja nimi on siis eksitav. Hakkaks näiteks poisslapse nimesid panema css'is ja js funktsioonidele ning muutujatele. Jürgen on näiteks üks tore menüüscripti nimi. Või siis Paul.

    24. mai 2013 - 12:05:07 · Otselink

    3

    • lahendus on enda jaoks ka kõik namespaceda , siis keegi namespaceb ja siis seda namespacetakse ja siis namespaced namespacevad üksteist

    • ja kaugel ei ole ka namespace konflikt :D

    Loe kõiki

  • friizuurikas 11 a

    : ) Nüüd võib selle targa jutu peale näiteks ette võtta 20 viimati pixlisse postitatud agentuuride tööd ja vaadata mis tegelik olukord html/css on, ega midagi väga rõõmustavat just mitte ...

    24. mai 2013 - 16:34:16 · Otselink

    3

    • ole nüüd :) siin threadis on ju kohati päris asjalik arutelu, kahju lihtsalt, et need tõed sageli IRL koodi ei jõua

    • olukord ongi veits nutune, ma olen t2iega n6us. aga agentuuri mentaliteet ei hakka vist kunagi "kvaliteet yle kvantiteedi" k2ima.

    Loe kõiki

  • friizuurikas 11 a

    "Kui sa algusest lõpuni asja ise valmis kirjutad siis reaalsuses vahet pole. " - peale selle et kood on lühem ja renderdus kiirem, aga kas ma siit järeldan, et puht teoreetiliselt asja õieti tehes on ikkagi ID parem, aga praktikas class mugavam ?

    24. mai 2013 - 22:11:50 · Otselink

    3

    Loe kõiki

  • friizuurikas 11 a

    Jeffrey Zeldman samal teemal ... kometaarides on ka umbes samad väited ja vastuväited nagu siin läbi jooksnud juba : )

    28. mai 2013 - 09:54:38 · Otselink

  • rain 11 a

    jah kui ehitad 2 lehevaatega blogi.

    aga isegi siis ja suuremate projektide puhul segu http://smacss.com/ + http://bem.info/ on märksa jätkusuutlikum. ja imo ka semantilisem kui see kellegi jaoks nii väga oluline on.

    28. mai 2013 - 10:31:38 · Otselink

    5

    • Rain räägib CSS kirjutamise metodoloogiatest, mille läbi saad oma html/css muuta modulaarsemaks ja pikemas plaanis paremini hallatavaks.

    • carl , aga me saame väga hästi aru millest ta räägib

    Loe kõiki

  • friizuurikas 11 a

    imho on jätkusuutlik kirjutatada standardile vastavat ja mõtestatud koodi ja mitte üle erutuda kõikidest frameworkidest, toolidest jne (kuigi nende kasutamises pole midagi halba), siiski peaks meeles pidama, et nad tulevad ja lähevad. Pigem trendi kaup ... Suure tõenäosusega pole smacss ja bemiga 5-10 aasta pärast suurt midagi peale hakata.

    28. mai 2013 - 19:20:14 · Otselink