Eli mikä sivu on missä on kotisivulle esim. taustakuvia ja erilaisia vihjeitä ja semmosia?
kotisivu ohjeita ja vihjeitä?
Onkó?..
101121
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Turvaa tilisi vahvistamalla puhelinnumerosi. Voit silloin palauttaa unohtuneen salasanan tekstiviestillä.
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 10
Vanhimmat
Opettele html ja css, unohda javascript.
Kotisivuja tehdessäsi testaa ne ensin jollain oikealla selaimella (muu kuin IE), niin niistä tulee ehkä toimivatkin.
IE:ssä näkyy selkeät merkit amatöörimäisyydestä; vaikka html:ää ja css:ää ei ole saatu toimimaan, niin on kuitenkin pitänyt lähteä tekemään omia 'kivoja' lisäyksiä, jotka eivät sitten edes toimi standardin mukaisilla selaimilla. Ammattilaiset tekevät ensin toimivan tuotteen, ja vasta sen jälkeen aletaan tehdä jotain 'nice to have' härpäkkeitä.
Eli tarkoitin et ku on 1 sivu joten en muista olisiko ollut joku seijan, saijan, katin tai joku semmonen kotisivu missä oli hyviä vinkkejä eli miten saa esim. teksin liikkumaan tai kuvat ja jne..
"miten saa esim. teksin liikkumaan tai kuvat"
Nuo on juuri niitä js-kikkareita, joilla saat sivut toimimattomiksi tai ainakin kävijät karkoitetuiksi.
Vaikka sivut on kuinka täynnä animaatioita, vilkkeitä ja kilkkeitä, niin kukaan ei käy siellä kahta kertaa enempää.
Sen sijaan jos sivuilla on sisältöä, joka vielä uudistuu, niin kävijöitä riittää.
Jos osaat html:n ja css:n, niin se riittää. Unohda nuo kikkareet, koska niillä saat vain kertakäyttöasiakkaita.
Onko väsyneellä suuriakin JavaScript-traumoja? Olen huomannut että kehoitat ihmisiä monessa poustissa kirjaimellisesti unohtamaan JS:n.
Vaikka JavaScriptiä käytetään monta kertaa turhaan ja väärissä tilanteissa on sillä myös hyödyllisiäkin tarkoituksia esim:
* Palaute/Tilaus lomakkeen esikäsittelyssä (toki sama käsittely pitää turvallisuussyistä tehdä palvelinpuolella). Tämä säästää kaistaa ja nopeuttaa virheellisten lomakkeiden käsittelyä
* CSS yhteensopivuuden aikaansaaminen eri selaimissa, jossa CSS määrittely ei löydy tai tai se on bugisesti toteutettu. Tämä koskee luonnollisesti vain yksinkertaisia tapauksia.
* Yksinkertaisten dynaamisten sivujen luontiin silloin kun se helpottaa käyttäjää sivun sisällön hahmottamisessa ja ymmärtämisessä.
Kyllä JavaScriptin peruskäyttö kannattaa opetella mutta sitä pitää käyttää maltillisesti ja vain silloin kun siitä on jotain todellista hyötyä.
" Onko väsyneellä suuriakin JavaScript-traumoja? Olen huomannut että kehoitat ihmisiä monessa poustissa kirjaimellisesti unohtamaan JS:n. "
On traumoja. Olen törmännyt satoihin sivuihin, joissa sivut, varsinkin linkit, on tehty toimimattomiksi js:n avulla. vaikka sama voitaasiin tehdä ilman js:ää (tai ainakin toimiviksi js-disabled selailijoita).
" Palaute/Tilaus lomakkeen esikäsittelyssä (toki sama käsittely pitää turvallisuussyistä tehdä palvelinpuolella). Tämä säästää kaistaa ja nopeuttaa virheellisten lomakkeiden käsittelyä "
Aika harvassa nuo modeemikäyttäjät on nykyisin - ja miksi heidän takiaan sivuista pitäisi tehdä käyttökelvoton.
"CSS yhteensopivuuden aikaansaaminen eri selaimissa, jossa CSS määrittely ei löydy tai tai se on bugisesti toteutettu. Tämä koskee luonnollisesti vain yksinkertaisia tapauksia"
Useimmissa selaimissa css toimii suht hyvin (paitsi IE:ssä). Tätäkin varten netistä löytyy hackeja mielin määrin.
"Yksinkertaisten dynaamisten sivujen luontiin silloin kun se helpottaa käyttäjää sivun sisällön hahmottamisessa ja ymmärtämisessä"
Ehkä joskus noinkin voi olla. Mutta miksi siltä järkevimmältä osalta selaajista pitää samalla hävittää koko sivun sisältö samalla.
" Kyllä JavaScriptin peruskäyttö kannattaa opetella..."
Miksi?
"...mutta sitä pitää käyttää maltillisesti ja vain silloin kun siitä on jotain todellista hyötyä"
Näinpä. Ihmettelen vain mikä on se käyttö, mihin js:ää oikeasti todella tarvitsee.
Jos pystyt esittämään jonkin käyttökohteen, jossa js:ää oikeasti tarvitsee, niin en enää koskaan vinoile js:n käytöstä (pl toiminnallisuus, joka voidaan tehdä myös php:n avulla).
Mutta summa summarum; 99,9% js:stä on pelkkää kilkepelleilyä.
Suurimpia virheitä, mitä kotisivuntekijä voi tehdä on:
1) Tehdä sivuille pelkästään IE:llä toimivia kikkareita.
2) Tehdä sivuille js-kikkareita niin, että ilman js:ää sivut ovat toimantakyvyttömät.
.
.
.
3) 1000 km:n päässä voi tulla jotain muuta; esim laittaa viruksia sivuilleen tms.
...pohjalta marginalisoit JavaScript käytön 99.9% hyödyttömäksi
>>
"On traumoja. Olen törmännyt satoihin sivuihin, joissa sivut, varsinkin linkit, on tehty toimimattomiksi js:n avulla. vaikka sama voitaasiin tehdä ilman js:ää (tai ainakin toimiviksi js-disabled selailijoita)."
>>
Minä peräänkuulutinkin JavaScriptin asiallista käyttöä, siksi käyttäjiä pitäsi opettaa koska JS:ää pitää käyttää ja koska ei. Heille EI pitäisi sanoa kategorisesti että sitä ei kannata opetella.
Kuinkakohan monta kertaa olen nähnyt HTML&CSS:ää "käytettävän väärin", ei JavaScript ole tuossa mikään poikkeus, se on käyttäjistä kiinni, *ei* itse työkaluista.
>>
"Aika harvassa nuo modeemikäyttäjät on nykyisin - ja miksi heidän takiaan sivuista pitäisi tehdä käyttökelvoton."
>>
Jos välttämättä haluat tarjota 100%:isesti saman sivupalvelun niille muutamalle prosentille käyttäjistä joilla on JavaScript poiskytkettynä niin se on tietenkin oma valintasi.
Jos JavaScriptin haluaa pois turvallisuussyistä, niin silloin pitää myös "kytkeä pois" monia muita asioita, Internet Explorer selain ensimmäisenä.
Yli 80% koneista on spywaren saastuttamia, ActiveX kontrolleja tyrkytetään useilla sivuilla jne..kyllä kirveelle löytyy työtä muualta ensin.
>>
"Useimmissa selaimissa css toimii suht hyvin (paitsi IE:ssä). Tätäkin varten netistä löytyy hackeja mielin määrin."
>>
Just ...eli sinä käytät mielummin "hackeja" kuin JavaScriptia jos haluat kiertää bugisen/puutteellisen CSS-tuen valtaselaimissa?
Aina ei löydy toimivaa CSS-hackia, esim. en ole ikinä nähnyt pelkän CSS:n varaan rakentuvan mielivaltaisesti alivalikkoja mahdollistavan menurakenteen joka toimisi *moiteettomasti* valtaselaimissa (IE5+, Opera7+, Mozilla/Netscape7+, Safari jne) JA joka on myös toimiva tulevissa selaimissa ..ilman että sitä tarvitsisi hiukan viilata JavaScriptillä.
Jos esim IE6:ssa on bugi/puutteellinen CSS-toiminnallisuus jonkun CSS määritelyn suhteen, niin mistä tiedät että se on korjattu seuraavassa IE selaimessa??
Näen usein näitä n.s hackeja jotka kyllä korjaavat bugin tämänhetkisissä selaimissa, mutta samalla he lukitsevat itsensä tilanteeseen jossa ei ole varmuutta siitä onko k.o toiminallisuus puutteellinen/buginen/osittain toimiva seuraavassa IE selaimessa.
Hyvä esimerkki on listelementteihin perustuvissa menurakenteissa jossa IE selaimissa on täysin mielivaltaisia margineita listaelementtien välillä tietyissä tilanteissa.
Tämä voidaan korjata CSS hackeilla mutta he ovat olettaneet (IE5:sta lähtien) että asia on korjattu seuraavassa IE selaimessa, mutta eipäs ole vieläkään...
Monet hackia käyttävät arvelivat että k.o bugi on korjattu IE6:ssa ja syöttivät hacky-CSS määritelyn IE5&IE5.5 selaimelle (esim IE5.* parserbugeja hyödyntäen), mutta metsään meni...
Minä en ainakaan halua mennä läpi (ja korjata) kaikki tekemäni sivustot muutaman vuoden päästä ja todeta että CSS hackit eivät toimineetkaan tulevissa selaimissa, teen mielummin toimivan kokonaisuuden jota tarvittaessa puukotan hieman JavaScriptilla ECMA-262 ja W3C standardien mukaisesti.
>>
"Jos pystyt esittämään jonkin käyttökohteen, jossa js:ää oikeasti tarvitsee, niin en enää koskaan vinoile js:n käytöstä (pl toiminnallisuus, joka voidaan tehdä myös php:n avulla). "
>>
Edellä ja aikaisemassa postissani esitin jo useita näkökohtia, tämän lisäksi olen käyttänyt JavaScriptia kun teen sivuston muokkaamista varten räätälöidyn päivitysjärjestelmän yritykselle.
Koska päivityssivu on salasanasuojattu voin olettaa että sitä käyttävät vain yrityksen henkilökunta jolloin voin tehdä kaiken tarvittavan esikäsittelyn selaimessa (ja unohtaa palvelinpuolen kokonaan), mikä nopeuttaa ja helpottaa järjestelmän rakentamista ja tietojen käsittelyä *huomattavasti*.
Ei tulisi mieleenkään että ajaisin palvelinohjelman jokaisesta käyttäjän tekemästä valinnasta, se olisi kaistan tuhlausta, palvelinresurssien tuhlausta , käyttäjän työajan (= rahan) tuhlausta ...
...ja ennenkaikkea päivityssivun senhetkinen "tila" tuhoutuisi joka kerta kun suorittaisin palvelinpyynnön ja sivu latautuisi uudestaan.Toki on mahdollista tehdä RPC-kutsu ilman että sivu lataantuu uudestaan (XMLHttpRequest / piilotettu IFRAME jne), mutta niidenkin käsittely vaatii JavaScriptia.
>>
"Mutta summa summarum; 99,9% js:stä on pelkkää kilkepelleilyä. "
>>
Joo, olen törmännyt vastaavanlaisiin tapauksiin muissakin asioissa, kun tarpeeksi alkaa uskotella itselleen että jokin asia on huono niin kyllähän se mieli lopulta taipuu uskomaan siihen, vaikka kaikki seikat eivät tukisikaan sitä "illuusiota".
Olisit edes sanonut 99% niin olisin voinut jotenkin ymmärtää mutta 99.9% meni jo trollauksen puolelle :))
Jacce
»Minä en ainakaan halua mennä läpi (ja korjata) kaikki tekemäni sivustot muutaman vuoden päästä ja todeta että...»
Niin katsos sitä varten niitä ei kannatakaan laittaa jokaiselle sivulle erikseen. Esim tuon pudotusvalikon JS IE:tä varten pistetään ulkoiseen tiedostoon. Jos on tarve korjata niin ei sitä tarvitse joka sivulta erikseen korjata.
Tämäkin kuuluu sivuston järkevään suunnitteluun.
»Kuinkakohan monta kertaa olen nähnyt HTML&CSS:ää "käytettävän väärin", ei JavaScript ole tuossa mikään poikkeus, se on käyttäjistä kiinni, *ei* itse työkaluista.»
Jaan tuon mielipiteen kanssasi. Näin se vain on.
Parhaat w-sivut ovat selkeästi luettavia, ei mitään erikoistehosteita jotka pomppivat silmille kun sivu aukeaa. Asia/kuvat/linkit selkeästi esille elikkä se mitä mainostat, mainosta sitä eikä mitään animaatiopelleilyjä. Sellaiset sivut joissa paljon tehosteita antavat yrityksestä helppo-heikin maineen. Sama pätee myös mainoksissa käyntikorteissa, tyhjä krääsä pois ja asia paperille.
>>
"Niin katsos sitä varten niitä ei kannatakaan laittaa jokaiselle sivulle erikseen. Esim tuon pudotusvalikon JS IE:tä varten pistetään ulkoiseen tiedostoon."
>>
Pistän aina kaikki sivuston yhteiset rakenteet kuten logopalkki, menupalkki ja copyrightpalkki erilliseen tiedostoon, joko palvelinpuolella jos palvelin ei ole ruuhkainen ja sallii serverside-includet, tai sitten erilliseen .js tiedostoon normaaliksi aliohjelmaksi joka generoi palkkikoodin.
Tällä tavalla joudun tekemään muutokset vain yhteen paikkaan. Väsynyt nimimerkin kommenteista huolimatta tämäkin on yksi asia jonka usein jätän käyttäjän koneen suoritettavaksi (JS:llä) *en* palvelinkoneen, minä pidän positiivisena sitä että palvelinkuormaa voidaan siirtää käyttäjän koneelle (olkoonkin että se muutama prosentti JS-OFF käyttäjistä siitä kärsivät, heille teen kyllä aina vähintään ilmoituksen ja
mahdollisesti jonkun yksinkertaisen sitemapin)
>>
" Jos on tarve korjata niin ei sitä tarvitse joka sivulta erikseen korjata.
Tämäkin kuuluu sivuston järkevään suunnitteluun."
>>
Niinpä, mutta mieluiten en korjaa ollenkaan vanhoja sivustoja uusien selainten tullessa markkinoille jos voin sen suinkin välttää.
Jos esim jokin tämänhetkinen selain tukee tiettyä JavaScriptin ECMA-262/W3C standardin mukaista rakennetta niin on perusteltu syy olettaa että näin on myös saman selaimen seuraavassa versiossa --- samaa ei voi sanoa kun kyse on esim. bugisen/puutteellisen CSS-tuen korjaaminen "hackeilla".
Muistakaa että (varsinkin pienyritykset) yritykset eivät ole mitään hyväntekeväisyysjärjestöjä ja sosiaalitoimistoja, eivät heitä aina kiinnosta palvella jokaista webikäyttäjää (esim. nyt juuri niitä joilla on JS poiskytkettynä) jos se tarkoittaa joko sitä että näille käyttäjille pitää tehdä toisenlainen toteutus (= maksaa lisää), tai jos vaihtoehtoinen toteutus --- kokonaan palvelinpuolella toteutettu -- aiheuttaa palvelun hidastumista, hankaloittaa vuorovaikutteisuutta sivustossa ja (usein) myös monimutkaistaa toiminnallisuuden toteuttamista.
JavaScript tarjoaa myös mahdollisuuden toteuttaa (kuten mainitsin toisessa postissa) esim. wysiwyg päivitysjärjestelmän käyttäen hyväksi MSHTML Editorin designMode ja execCommand() metodeja (toimii IE5.5 ja uusimissa Mozilloissa), jolloin asiakas voi päivittää kätevästi sivustoa salasanasuojatulla päivityssivulla.
Minusta pitää valita työhön kuin työhön oikea työkalu, jos jonkin asian voi tehdä asiakaspuolella niin en näe syytä miksi sen pitäisi siirtää palvelinpuolelle (= ajan&kaistan haaskamista, vuorovaikutteisuus & odotusaika & käyttäjäystävällisyys heikkenee) ja eritoten sivun senhetkinen tila menee romukoppaan joka kerta kun sivu ladataan uudestaan palvelinohjelman ajon seurauksena, PHP sessionit voivat kyllä olla avuksi tässä mutta vain yksinkertaisimmissa tapauksissa.
Jacce