Webkafeen

[TSP]

Dahl. Jeg får like fnatt av den siste, noe jeg oppdaget mye av på nett i dag når jeg søkte rundt var;

 

body 
{
background:white;
}

 

Det ble jeg irritert på det!

 

Har nok med at det for min del må være luft mellom tekst for at det skal bli oversiktelig.

 

Forresten Dahl, du bør lære deg å avslutte taggene dine . Slik:

body {
background: white;
}

 

 

 

(det siste var en dum dum spøk/ironi)

Endret 13. mars 2008 av TSP

[Lovskogen]

#foo .bar p {
    text-align: center;
    text-decoration: none;
}

 

Om det bar er kode på én linje:

 

#foo .bar p {  text-align: center  }

[Sono Juventino]

Jeg pleier å legge korte kodesnutter på èn linje. Spesielt når det bare er snakk om farger, font-greier osv.

 

Nå har jo alle snakket om hvordan de koder, så det gidder ikke jeg kommentere.

 

Jeg deler alle mine stilark inn i seksjoner. Har alltid det generelle først, så starter jeg med grunnlayouten. Da er det snakk om header, evt "wrapers" og footers. Derreter kommer innholdet i logisk rekkefølge, altså øverste elementer øverst og nederste nederst. Det vil si at footer { kode } og footer p { kode } ikke ligger på samme sted for min del.

 

Jeg bruker også kommentarer over hver del som /*--- Meny --- */.

[loathsome]

What Tor said.

[PT]

Jeg får fnatten av sistnevnte... Dette er vel velkjent for dere VikingBoard-folk også, eller hva?

jorgis liker å skrive sistnevnte, men det er jo helt horribelt. Finnes nok hauger av commits til screen.css av meg som bare legger til et par mellomrom her og der

[Lovskogen]

Bruker litt større kommentarer á

 

/* Overskrift

--------------------------------------- */

 

Har det vanskelig for å dele form/luft og typografi/farge, men det er nok det beste.

[qualbeen]

Jeg er fan av flere stilsett! Blir ikke lengre lastid nei - med mindre du har gjentagende kode i de ulike stilsettene. Uansett: hvor lang tid tar det å laste ned 3 kilobyte ekstra?

 

Antar stilsettene har samme navn som sidene du inkluderer (templates, e.l.) og da er det lett å gjøre det automatisk også (er forsåvidt lett å automatisere inkludering av css uansett, men ).

 

Det samme gjelder java script: inkluder kun de du har bruk for! Og hvis både css og js lagres i eksterne filer kan nettleserne cache de, hvilket gir bedre lastetid.

 

EDIT: kanskje en idé å trykke refresh før jeg svarer? :o

 

Men mellomrom etter kolon? Hva er det godt for? NEI, fysj og fy!

Og klammene kan ikke stå på egen linje slik, jeg bruker java-konvensjonen der...

Smaken er som delt, som de sier på RR

Endret 13. mars 2008 av Halvis

[Lovskogen]

Er vel ikke antall kB som er poenget, men http-requests?

[jorgis]

Jeg får fnatten av sistnevnte... Dette er vel velkjent for dere VikingBoard-folk også, eller hva?

jorgis liker å skrive sistnevnte, men det er jo helt horribelt. Finnes nok hauger av commits til screen.css av meg som bare legger til et par mellomrom her og der

 

Pøh, gjør jeg da ikke. Jeg indenterer i hvert fall skikkelig!

 

Men når det kodes annet enn CSS, _må_ koden ha { } på egne linjer. Ellers friker jeg litt ut.

[qualbeen]

Er vel ikke antall kB som er poenget, men http-requests?

Poeng der, men er jo kun ved første forespørsel det blir flere requests.. Vil heller aldri falle meg inn å bake inn bilder i html-koden. Så nei, jeg er ikke redd for antall requests. Men alt med måte: bare tøys å ha en unik fil pr css-linje likzom. Men folk er jo ikke så dumme uansett, så ...

 

Anbefaler folk å velge den løsningen som er enkel for en selv/utviklings-teamet. Hva andre måtte mene er egentlig ikke så viktig ang. oppdeling av CSS-filer. Men virker nå som de fleste er for uansett

 

@jorgis: uff, forstår ikke at du klarer å lese kodelinjer som starter med en '{'. Grøsser :!:

[Haraldson]

Enig med Jørgen mtp. programmering, men når det kommer til CSS ser jeg virkelig ikke poenget med egne linjer for klammene. Det blir bare rotete, da man bare har alle selektorene rett under hverandre uansett.

 

Argumentet for å ha første klamma på egen linje er ofte 'bedre leselighet', men det får du jo vitterlig av å indente egenskapene og verdiene og på den måten la selektorene være det eneste i et stilark som begynner helt ytterst i venstre marg, ikke av å lage egne linjer for klammene.

 

Følger denne praksisen uansett;

 

selektor {
egenskap: verdi;
}

elem {
egenskap: verdi;
egenskap: verdi;
}

 

Samme om det er én eller 20 linjer, det skal så ofte en eller to egenskaper til inn innenfor klammene at jeg like greit legger opp til det uansett. Litt på samme måte som i programmering og if/else-tester og klammer/ikke klammer. Alltid semikolon etter siste verdi av samme grunn.

 

Har i tillegg omtrent standardisert måten jeg deler opp stilarkene på;

/*	______________________________________________________________
  SEARCH RESULTS											  */

Tre tomme linjer over, én under.

 

Har aldri sett noen fordeler med å dele opp stilarkene til flere filer, skal man f.eks. ha en for fonter og en for farger ender man opp med haugevis av like selektorer. Eneste gangene jeg bruker like selektorer er for å overstyre, ellers liker jeg at all stiling som skal assosieres med en spesifikk selektor finnes på ett og samme sted.

[MC2]

Jeg kjører mer eller mindre samme syntax som Haraldson, bare at jeg ikke er vant med det mellomrommet mellom property og verdi. Jeg liker derimot å dele opp css-en i flere filer (noe jeg bare er vant til med hensyn til kategorisering). I gjenngjeld så skrev jeg nylig en klasse for sammensveising av css filer for å redusere http requests samtidig som den komprimerer koden (blir kvitt alle kommentarer og whitespace). Når jeg komprimerer så reduserer jeg filstørrelsen med 15-25%, noe som egentlig er ganske betydelig.

[jorgis]

Når det gjelder komprimering av .js og .css-filer; jeg ser ærlig talt ikke hvorfor en skal bruke masse tid på å komprimere en fil med stakkarslige 15-20% når en like greit kan slå på gzip-komprimering fra serverside, og heller komprimere _ALT_ 80+%.

[MC2]

Når det gjelder komprimering av .js og .css-filer; jeg ser ærlig talt ikke hvorfor en skal bruke masse tid på å komprimere en fil med stakkarslige 15-20% når en like greit kan slå på gzip-komprimering fra serverside, og heller komprimere _ALT_ 80+%.

Er jo greit å komprimere filene 15-25% først, også med gzip. Fil på 1024kb kommer da ned på ca 164kb istedet for 205kb. Er ikke allverden, men er litt for feks. mobiler der folk betaler for båndbredde.

 

Hmm, visste ikke at gzip komprimerte så mye. Trodde det bare var 10% eller noe..

Endret 13. mars 2008 av MC2

[prebenl]

Må bare få skyte inn at startklammen bør stå på slutten av linjen, både i CSS og i kode. Blir vel en preferansesak, men i f.eks. "Code Conventions for the Java Programming Language" står det eksplisitt nevnt at det skal gjøres slik.

 

Poeng der, men er jo kun ved første forespørsel det blir flere requests..

Hva, det er vel en http-request for hver enkelt CSS-fil? Løsningen er vel å ha dem separert for leselighet og struktur, og heller kjøre dem sammen med et script når det skal deployes til produksjonsserver. Er jo en fordel å separere dem når de blir betraktelig store, for lettere å kunne vedlikeholde dem, og for å gjøre det lettere for fremmede å finne frem.

 

Når det gjelder komprimering av .js og .css-filer; jeg ser ærlig talt ikke hvorfor en skal bruke masse tid på å komprimere en fil med stakkarslige 15-20% når en like greit kan slå på gzip-komprimering fra serverside, og heller komprimere _ALT_ 80+%.

Støtter alle browsere gzip-komprimering? Er vel uansett ikke mer arbeid å forhåndskomprimere enn å ha et script som kjøres automatisk ved deploy.

Endret 13. mars 2008 av Geofrank

[jorgis]

Når det gjelder komprimering av .js og .css-filer; jeg ser ærlig talt ikke hvorfor en skal bruke masse tid på å komprimere en fil med stakkarslige 15-20% når en like greit kan slå på gzip-komprimering fra serverside, og heller komprimere _ALT_ 80+%.

Støtter alle browsere gzip-komprimering? Er vel uansett ikke mer arbeid å forhåndskomprimere enn å ha et script som kjøres automatisk ved deploy.

 

Alle store, AFAIK. IE6, IE7, Firefox, Opera, Safari, Opera Mini ++. Forhåndskomprimere i f.eks. gzip/gunzip går fint an, svjv, er da i så fall bare å spesifisere en ekstra HTTP-header (men en behøver uansett da et serversidespråk for å generere headeren).

[prebenl]

Alle store, AFAIK. IE6, IE7, Firefox, Opera, Safari, Opera Mini ++. Forhåndskomprimere i f.eks. gzip/gunzip går fint an, svjv, er da i så fall bare å spesifisere en ekstra HTTP-header (men en behøver uansett da et serversidespråk for å generere headeren).

Snertent. Det er ikke mulig å sette det som default i web-serveren (eks. httpd.conf i apache)? Ikke det at jeg ikke bruker noe serversidespråk, men det hadde vært litt mer ryddig.

 

Har du noen anelse om hvordan dette påvirker serverytelsen? Den må vel komprimere hver enkelt side for hver request, med mindre man bruker noen form for caching.

Endret 13. mars 2008 av Geofrank

[loathsome]

Et raskt script jeg mekket

http://yesplz.servebeer.com/random/is_netcom/

 

Veldig, veldig, veldig nyttig for dere som har NetCom og ringer gratis til andre NetCom-kunder!

[jorgis]

Geofrank: Jeg har dessverre ikke satt meg godt nok inn i hvordan dette fungerer, har hovedsakelig bare brukt det via PHPs API. Men etter det jeg har forstått, vil mod_deflate fungere fint om du ønsker å kjøre zlib-komprimering på alt av innhold (som en apache-modul). Det genererer selvfølgelig ekstra last på webserveren (gzip-komprimering er relativt cpu-intensiv), men for mindre sider eller sider hvor flaskehalsen ligger i båndbreddebruk (statiske/nesten-statiske sider) er det en genial ting å ha.

[PT]

@lottsåm: Hva baserer du det på?

Endret 13. mars 2008 av PT