cbastus

Jeg var i Stryn under åpningen.

Dessverre har de ikke fått opp parken som planlagt, de trenger maskinene til å utbedret t-kroken på breen. Truls (?) sin skishop på Folven er flyttet opp på fjellet med brett, longboards og vinterstæsj etter endring i leiepriser på Folven, shopen på Folven er bygget om og huser mer sommerting, og Aloa Hemp legger ned etter at mange av butikkene som pleide kjøpe fra de har gått konk under finanskrisa.

Altså ikke de beste nyhetene, men på den positive siden har Moods spyttet inn noe slikt som 30 mill etter hva de lokale fortalte, så det hele ender nok fint

Pirates of the Caribbean: On Stranger Tides

Nja. Virker som når en film har blir TV-serie, magien og atmosfæren har blitt borte og den virket masseprodusert.

Den svært særegne Captain Jack har blitt mer flat, det virker mer som han slenger ut catch phrases på løpende rekke en genuine improviserte replikker. Kjærlighetshistorien som følger med synes ikke å passe helt inn, historien hopper som om de har klippet bort meningsfulle scener for å få med mer action og selve plottet virker som det mest er der for å ha ennå en Pirates film. Det var litt synd å se Jonny Depp gi så mye mindre enn forventet, og det han ga dabbe av utover i filmen.

Jeg tror Orlando Bloom og Keira Knightley gjorde rett i å ikke bli med på nok en runde.

Alt i alt: Helt ok.

PS. Så filmen i 2D.

Anbefaler boken JavaScript: The Good Parts.

Som en referanse, ta en titt på http://javascript.crockford.com/style1.html

Takk for tipsene.

OT:

... Selv om det ikke er feil å gjøre slik:

var a = 1;
var b = 2;
var c = 3;

Så er det anbefalte måten å gjøre det slik som jeg gjorde:

var a = 1,
   b = 2,
   c = 3;

Er det virkelig anbefalt å liste opp lokale variabler på den måten i JS?

Jeg synes det gir mindre lesbarhet rundt hva som er lokale og hva som er globale variabler, med tanke på at "var" kun eksisterer inni nåværende scope i JS (aka. lokal), og at en variabel deklarert "someVar = foo;" vil leve i window scopet (aka. global). Jobber man med nøstede funksjoner og closure, ser jeg for meg at denne metoden fort kan bli messy.

Du kan med fordel komprimere bildene i slide showet på fronten mer.

Det samme gjelder de store bildene i slide showet under referanser.

Jeg tror vi diskuterer forbi hverandre.

...

Hva man deretter gjør i CSS er rett og slett irrelevant! (der finner jeg det uklart hva du egentlig mener.)

Kort fortalt er hva jeg mener at man ikke burde endre for mye på standardiserte elementer med CSS, bare fordi man har mulighetene til det. Som for eksempel å omdefinere hvordan elementer tegnes opp iht. W3C, eksempelvis SPAN[style=display;block] og P[style=display:inline], når dette kunne vært unngått ved å tenkte nøyere gjennom HTML strukturen.

(Skjermlesere vil fortsatt her vektlegge P som en paragraf, mens det visuelt kanskje nå er gjort om til en liste, et sitat eller noe annet som ikke burde vektlegges som et avsnitt.)

Jeg er imponert over at siden er så direkte/kommer til poenget raskt. Mange større aktører bommer på content, men det virker som du har vært flink. Siden forteller raskt hva dette er, hva de gjør, hvordan de kan gjøre det for meg. Du har også unngått fallgropen av flashyness og eye candy, noe som er bra. Det hadde vært spennende å vite om dette er gjort bestemt, eller om det er et resultat av noe annet.

Det du kan vurdere er å bruke litt mindre plass til bilder på forsiden, eventuelt få litt mer beskrivende tekst bedre frem. Du kan med fordel løse slideshowet med javascript da dette gir tilgjengelighet på mobile platformer (les iphone), som jeg vil anta det ikke er usannsynlig at målgruppen til en entreprenør bruke. Om dette ikke lar seg endre, burde du uansett la brukeren bla i slideshowet slik at den selv kan se på de bilder som vekker interesse. En liten beskrivelse av hvilke prosjekt det er og hva som er gjort, med lenke til referansen, kan kanskje også være en god ide (jeg anslår at Jarle Bygg får sine fleste kunder basert på referanser).

OT: Nidelva bygget ble grisefint: http://www.jarabygg.no/ref_1.html

Slik jeg ser det er det ikke helt gunstig å endre rendringen av elementer slik du beskriver (med display:inline på DIV, display:list-item på P og display:block på feks SPAN).

 

Om man må endre hvordan layout rendres så radikalt, synes jeg det er et signal om at HTML og content i utgangspunktet ikke er gjennomtenkt nok, og at man prøver gjøre opp for manglende fundament ved å male det i fine farger.

"Gunstig" er ikke noen god beskrivelse nei. For de som ikke forstår problemstillingen vil fort vekk "tvilsomt" ende opp som god beskrivelse, men for de av oss som forstår hva som er hva rundt og hvordan de forskjellige tingene her er ment å brukes, vil nok heller "irrelevant" være beskrivelsen.

Disse endringene går også utover andre ting, som feks tilgjengelighet. Skjermlesere, userstyles ol. får unødvendig med «støy» når de skal tolke sidene og man lager problemer for seg når en skal tilpasse sidene til ulike medier og browsere.

Dette er bra argumentert for hvorfor "riktig" HTML er bra og viktig, men det fungerer ikke som et argument mot å bruke CSS til å endre hvordan elementer brukes i layout.

«Tabeller er så 2001» er ikke et argument for å gå bort fra hvordan dataen er presentert på best måte. At tabeller ikke skal brukes til layout, betyr ikke alt all layout skal gjøres med andre HTML-elementer endret i CSS.

Da har du ikke sett poenget mitt, og neppe heller motivasjonen til CSS-arbeidsgruppa, når de gjorde "display" til en del av CSS. At du helt korrekt kan peke på to forskjellige ytterpunkter og slå fast at det er to dårlige fremgangsmåter, betyr ikke at det ikke finnes gode/smarte/riktige bruksområder i mellom.

 

Og nei, ingenting av det jeg skriver er et argument for "å gå bort fra hvordan dataen er presentert på best måte" - heller tvert imot.

Har man griddata er tabell fortsatt beste metode.

Kort og greit: Skal dataen din vises som tabell, bruk tabell. Skal det være en liste, bruk en liste.

Det viser egentlig bare din manglende innsikt i det du argumenter for (og som jeg er enig i): Ja, hvis innholdet er tabulært, så er det <table> som skal brukes. Men, nei, hvis greia er at innholdet skal ha grunnleggende layout ala en tabell, så er det ikke nødvendigvis <table> som skal brukes.

 

Det er jo dette som er hele fundamentet bak HTML og CSS!

Slik jeg forstå det du skriver, er vi enige. Så la meg utdype hva jeg mener:

Du understreker som meg at CSS er for visuell identitet, og at HTML er for struktur.

HTML burde vel da være så generisk og fjernet fra CSS som mulig, og CSS burde vel ikke blandes inn i strukturen?

Koden vi diskuterer bruker klasser som .table og .row og .cell, som berører hva jeg mener er problemet. Her synes jeg ikke man skiller HTML og CSS på en god måte. Det virker mer som at CSS er brukt til å gjenskape noe man tidligere har skapt i tabeller (men siden «tabeller er så 2001», har man valgt å gjøre det i CSS).

Slik jeg oppfatter best practise CSS og HTML er det en annen bruk som er optimal. Derfor står jeg fortsatt fast på at om målet er å lage en tabell, så kan man like gjerne bruke en tabell. Poenget med HTML og CSS er ikke å lage ekstra, unødvendig, kode for å tvinge frem et resultat. Poenget er vel å gjøre ting frittstående, mer tilgjengelig og renere? Når man blander inn spesifikke klassenavn, som beskriver hvordan man ønsker at HTMLen burde vært, og tukler med måten W3C beskriver at forskjellige elementer skal rendres på - da mener jeg man ikke har forstått hva som ligger til grunne for argumentet «tabeller er så 2001», og at man lager unødvendig bry for seg selv.

Det jeg ønsker å understreke er den ideen og tilnærmingen som frontes av prosjekter som http://www.csszengarden.com/, bedre beskrevet i denne artikkelen: http://woork.blogspot.com/2008/11/css-coding-semantic-approach-in-naming.html

Slik jeg ser det er det ikke helt gunstig å endre rendringen av elementer slik du beskriver (med display:inline på DIV, display:list-item på P og display:block på feks SPAN).

Om man må endre hvordan layout rendres så radikalt, synes jeg det er et signal om at HTML og content i utgangspunktet ikke er gjennomtenkt nok, og at man prøver gjøre opp for manglende fundament ved å male det i fine farger.

Disse endringene går også utover andre ting, som feks tilgjengelighet. Skjermlesere, userstyles ol. får unødvendig med «støy» når de skal tolke sidene og man lager problemer for seg når en skal tilpasse sidene til ulike medier og browsere.

«Tabeller er så 2001» er ikke et argument for å gå bort fra hvordan dataen er presentert på best måte. At tabeller ikke skal brukes til layout, betyr ikke alt all layout skal gjøres med andre HTML-elementer endret i CSS.

Har man griddata er tabell fortsatt beste metode.

Kort og greit:

Skal dataen din vises som tabell, bruk tabell. Skal det være en liste, bruk en liste.

Søker du etter konsulenter?

Kryssbrowser CSS er en hårete greie.

Om vi får se koden/testsiden kan vi hjelpe deg bedre.

Har du mulighet til å dele denne?

Rammeverk har kommet langt fra Dojo, Mootols og Prototypes spede begynnelse. I dag har JQuery trått frem som en favoritt blant mange frontend utviklere, og med utvidelser som JQuery UI, JQuery Mobile og det kommende JQuery Grid kommer antakelig ikke dette til å minke med det første.

Men, når passer det seg å begynne med rammeverk? Bør man kunne skrive lesbar, smart og funksjonell kode før man starter med rammeverk? Og hvor viktig er det å vite hva som skjer bak rammeverket? Trenger man vite hvordan DOM fungerer og hva som er spesifisert i W3C sin standarden for JavaScript og DOM? Trenger man inngående kunnskap i JS når et rammeverk gjør alt grovarbeidet, eller holder det å kunne bruke rammeverket godt?

Hva mener du?

Dessuten anbefaler jeg å vurdere jQuery ...

OT kommentar: Jeg synes for mange hopper rett på JQuery el., før de forstår hvordan JS fungerer. På måten scriptet til TS er skrevet, virker det på meg som at det kan være lurt å ta noen runder og kode fra grunnen før han hopper på et rammeverk.

.innerText er en ustandardisert metode, standarden er .textContent men denne støttes dessverre ikke av alle browsere.

Bytt til .innerHTML eller et rammeverk, så skal det fungere bedre.

EDIT: Merket meg forresten at du har timeout på 2000 ms. men du trekker av tiden med 1 sec.

Sist jeg bestilte noe som måtte fortolles fikk jeg tollpapirene i posten konto/kid til betaling. Den gang jobbet jeg rett ved tollvesenet på Alnabru, så jeg stakk innom i lunsjen, ordnet saken og fikk varen utlevert der.

Normalt sender tollvesenet pakken videre med posten når de har mottatt betaling.

Har også hørt at fortolling har skjedd i etterkant av mottak av pakken, hvor man får pakken, så betaler tollavgiften.

Husk at du også må tolle for frakt av varen.

(( varens verdi + frakkostnader ) * 1,25 ) + tollsats

Feilen ligger i måten du henviser til DOM-elementene på.

Det skal være nok å henvise til feltene med rett navn, gitt at flere felt ikke har samme navn.

JS:

function valider(skjema,felt)
{
  if (felt.value=="")
  {
     alert( "Skriv inn et gyldig antall." );
     felt.focus();
     return false ;
  }
  else
  {
     regEx = /^[0-9]{1,3}$/;
     OK = regEx.test(felt.value);
     if(!OK)
     {
        alert( "Antallet du har skrevet inn er ikke gyldig! Prøv igjen." );
        felt.focus();
        return false ;
     }           
  }
}
</script>

HTML:

<form action='' method='post' onsubmit='return valider(this,feltet);'>
  <input name="feltet" type="text" />
  <input type="submit" />
</form>

EDIT:

Vil du bruke document.getElementById() blir det slik:

<script type="text/javascript">
function valider(felt)
{
  var felt = document.getElementById(felt);
  // Her kan du med fordel sjekke om feltet eksisterer
  if (felt.value=="")
  {
     alert( "Skriv inn et gyldig antall." );
     felt.focus();
     return false ;
  }
  else
  {
     regEx = /^[0-9]{1,3}$/;
     OK = regEx.test(felt.value);
     if(!OK)
     {
        alert( "Antallet du har skrevet inn er ikke gyldig! Prøv igjen." );
        felt.focus();
        return false ;
     }           
  }
}
</script>

<form action='' method='post' onsubmit='return valider("feltet");'>
   <input id="feltet" type="text" />
   <input type="submit" />
</form>

Det er en rekke med ting som kan være galt her.

Start med å sjekke det grunnleggende:

1. Har koden din <html>, <head> og <body> tager som er rett plassert og avsluttes korrekt?
   
2. Har filene dine rett filnavn/extension?
   
3. Har du overført alle filene som designet avhenger av (CSS, bilder, JS, kildekode og annet)?
   
4. Har anonyme brukere på nettserveren tilstrekkelig tilgang til å lese filene?
   

Du kan med fordel legge en lenke til nettstedet ditt her, så kan vi enklere hjelpe deg. Slik det er nå, har du spurt et «hvor stor er en fisk»-spørsmål.

Søket til W3schools bruker Google, så om man har alle sidene statisk skal en kunne bruke Google Desktop Search og få omtrentlig samme resultat.

http://stackoverflow.com/questions/538865/how-do-you-archive-an-entire-website-for-offline-viewing

Forøvrig burde leksjon #1 i IKT vært: Google har svaret på alt.

På WiGO 2 ser det ut som det er en kube inni kuben, og at denne huser maskinvaren. Det sorte i bunn ser ut til å være lufting/avkjøling.

Ren kommentar: Det er greit å sjekke inputfeltene i omvendt rekke enn du gjør. Om du først sjekker alt er satt, så mer konkret hva som er satt og om det er gyldig, slipper du "feilmeldings looper" (i mangel av et bedre ord) hvor brukeren retter input for så å få beskjed om å rette noe annet ved neste submit. Det kan noen ganger også være fordelaktig å skrive ut alle feilmeldinger samlet.

Jeg har god erfaring med 980px i bredden. Det lar seg dele ganske greit opp i 3, 4, 5 og 6 kolonner også tar det høyde for den varierende bredden på scrollbar og annen chrome i de forskjellige nettleserne.

Edit: Merk at dette ikke er med tanke på pda/smatphones, der er 320px fordelt på en kolonne med 12-14px skriftstørrelse ganske greit.

Edit 2: Som en ren kommentar er det forresten ofte viktigere hvor mye whitespace man designer inn, enn hvor store grafiske elementer man skal ha.

The Dark Lurking (2010)

Virker som tre forskjellige regissører har fått bestemme hva de synes skulle være med for at filmen skulle selge, resultatet er en blanding av Resident Evil, The Exorsist, Evil Dead og Doom. Filmen er forøvrig også markedsført under navnet «Aliens vs. Zombies», selv om den mangler koblinger til Alien-franchiset.

Kort og godt: Ille, veldig ille. Ikke så ille at det blir bra, bare ille.

Uten å helt forstå hva du beskriver, høres det ut som du trenger å trigge et kall mot serverside for å oppdatere XML-filen via feks. ajax når noe skjer med tabellen.

For å få til dette kan du feks bruke JQuerys ajax funksjoner og hekt de på eventet/funksjonen som oppdaterer tabellen. Dette kan feks være en funksjon som sjekker at innholdet i samtlige inputt for en gitt rad ikke er blanke, hektet på "onblur" i de aktuelle feltene.

Hvorfor du fortløpende ønsker å oppdatere XML-filen er en annen sak. Vær bare klar over at dette vil krever litt ressurser av serveren din. Får du mange requests vil den knele ganske fort.