OBLIG 1 WEBUTVIKLING Oppgave 1 Gå gjennom nettsiden arngren.net og list opp alle problemene du ser. Både i funksjonalitet/bruk og i koden bak. Tar lang tid å laste inn siden: Mye bilder Mange animasjoner Mange elementer som er i bevegelse Dårlig struktur: Utallige div og span elementer Elementer som legger seg over hverandre Strukturen og utseendet er så dårlig at besøkende ikke tror at siden er ordentlig og dermed forlater de siden. Siden kan virke useriøs og frastøtende: Mye forskjellige farger Utallige linker Mange måter å nå samme linken på Flere søkemotorer på siden En setning kan inneholde mer enn 3 forskjellige farger på ordene. Julemotiv året rundt Dårlig betalingsside Hvis vi ser på kodingen til siden, blir vi møtt av et kaos uten like. Bildet ovenfor viser bare en liten brøkdel av den håpløse koden. Siden inneholder over 1500 div- elementer. Null system i koden, ingen struktur dette vil igjen gjøre det vanskelig å vedlikeholde siden, eller legge inn ny informasjon. Jeg kjørte siden i W3C s html validator og fikk opp at det er 613 errorer og 13 advarsler(!!!!!). Kjørte også nettsiden i W3C s css validator og fikk følgende beskjed Sorry! We found the following errors (8864). Dette er en tydlig indikasjon på at siden omtrent burde vært bannlyst på grunn av sin dårlige utforming.
Oppgave 2 Lag et eksempel som illustrerer nytten av/hensikten til multiple classes. Ligger i egen link på nettside.http://www.itstud.hiof.no/~larspeta/oblig.html Oppgave 3 Lag eksempler der du tester ut box modelprinsippet og flest mulig av css- egenskapene som gjelder box model. Eksemplene skal ikke ha noe fornuftig innhold. Ligger i egen link på nettside. http://www.itstud.hiof.no/~larspeta/oblig.html Oppgave 4 Finn eksempler på (deler av) nettsider som ikke skiller innhold og design på en god måte. Beskriv hva som er galt og hvordan det kan fikses. Diskuter spesielt tvilstilfellene. http://www.viaplay.no/ Utviklerne av viaplay sin webside har brukt my koding fra javascript direkte inn i HTML- koden, det er eksempel hvordan skillet mellom innhold og design skal gjøres. Måten dette kunne vært løst bedre på, ville vært med en egen <script>link i <head>delen av HTMLkoden isteden.
Oppgave 5 Beskriv tjenester/funksjoner du selv kommer opp med som bruker strukturelle tagger på en fornuftig måte. En funksjon jeg skulle ønske fantes på typisk smarttelefoner og tablets var, at når du skal velge i en variant av en dropdown meny så kunne du holdt fingeren over menyen valgt en funksjon som het utvid element. Og du hadde fått opp listen i dropdown menu på full skjerm, kunne valgt det du skulle ønske, og du hadde havnet på siden du valgte. Ganske så lik funksjonen åpne i et nytt vindu. Så slipper man å skulle zoome inn for å treffe riktig knapp, eller som mange gjør satse på at de treffer riktig knapp uten å zoome tror dette hadde blitt en funksjon som hadde blitt verdsatt. En annen funksjon som kanskje kunne ha vært en god i ide ville vært at man nederst på en webside kunne lagt inn en tag med dato, tid, og sted. Som ville endret seg ut ifra hvor besøkende befant seg, for å så loggføre i hvilket område flest er interessert i din side. Kanskje mest ønskelig innenfor butikkenes websider. Da kunne de sett i hvilket område (ta for eksempel postnummere), det var mange som var inne å så på varene deres. Deretter kunne butikken ha sendt ut reklame til nettopp dette postnummeret for eksempel. Oppgave 6 Lag flere små eksempler som illustrerer/tester ut de ulike posisjoneringsteknikkene/måleenhetene i CSS. Eksemplene skal ikke ha noe fornuftig innhold. Ligger i egen link på nettside. http://www.itstud.hiof.no/~larspeta/oppg6.html
TIDLIGERE EKSAMENSOPPGAVER WEBUTVIKLING Oppgave E1 Du har følgende webside. Hvilke tagger vil det være naturlig å velge for å angi de 7 rektangulære områdene? Omrisset rundt selve siden teller også med, og er markert ved bokstaven G. Den grå fargen er satt på taggen <body>. Husk at en tagg kan ha andre tagger "inni" seg. Det er kun taggen som matcher selve boksen som du skal angi. Prøv å tenke semantikk så sant det er mulig. Svar ved å skrive navn på felt og tagg: A <header> B <nav> C <article> D <aside> eller som en av to <section> med float right. E <aside> eller som en av to <section> med float right. F <footer> G <main>
Oppgave E2 Hvilke av disse punktene er vanligvis med i en valideringssjekk for HTML (ta utgangspunkt i w3c sin validator i strengeste innstilling). Å angi et punkt som er feil vil telle negativt. 1. Sjekker at det kun er benyttet gyldige tagger og tilhørende attributter. 2. Sjekker at tabeller ikke er benyttet til layout. 3. Sjekker at linker ikke er døde (at det de peker til finnes) og at bildefiler som det blir referert til i imgtagger eksisterer. 4. Sjekker at riktige semantiske tagger er brukt i forhold til innholdet. 5. Sjekker at strukturen i koden er korrekt (dvs. at tagger avslutter i riktig rekkefølge osv.) 6. Sjekker at koden er riktig indentert. 7. Sjekker at websiden er tilpasset mobil, print og andre medietyper på en riktig måte. 8. Sjekker at man benytter tagger "inni hverandre" på en riktig måte (f.eks. at title- taggen ikke kan stå inni en bodytag osv.) 9. Sjekker at siden er tilpasset en rekke kriterier i forhold til SEO (f.eks. at title ikke inneholder med enn 70 tegn, at alle bilder har alttekst og at menyer er bygget med listepunkter) 10. Sjekker at websiden ikke tar for lang tid å laste (dvs. for store bildefiler, for mye multimedia osv.) Angi kun nummeret til punktene som du mener er riktige i din besvarelse: 1, 3, 8
Oppgave E3 Hvilke feil ser du ved følgende kode (en samling av feil som ble gjort på obligene). Du skal vurdere koden ut i fra HTML5 skrevet i XML/XHTMLstil med vanlig praksis for struktur og kodeoppsett. Ikke ta hensyn til at siden mangler meny, semantiske tagger osv. Se kun på feil ved den koden som faktisk er der. NB! Du skal svare på oppgaven som en ryddig punktliste, der én feil er ett punkt. Dersom samme feil gjentar seg flere steder, kan du dekke alle feilene i samme punkt. Angi også hva som ville være riktig dersom dette ikke går frem av feilbeskrivelsen. <header>taggen skal ikke være med i <head> Mangler <body>tag Feil filtype på bildet i <img>taggen, det skal være enten,.jpeg,.png, eller.gif. <img>taggen mangler altattributtet. Mangler en </p> i bunnen av koden. Mangler generelt innrykk, noe som vil gjøre koden mer ryddig og velformet.
Oppgave E4 I CSS finnes det (minst) fem ulike "nivåer" av stilark: Inline Internal External User Browser C'en i CSS står for cascading ("sammenfallende" er en upresis norsk oversettelse som ofte er brukt). Forklar hva dette begrepet betyr i sammenheng med at det finnes ulike "nivåer" av stilark. Bruk som minimum internal og external som et konkret eksempel på din forklaring. Det er vanskelig å komme på en spesifikk oversettelse av Cascading Style Sheets (CSS), men vi kan si at det er flere stilark satt sammen for å komme med det beste produktet seriekopla stilark kan være aktuelt å bruke. External hensiktsmessig når vi skal appellere til mange sider, men et eksternt stilark kan vi forandre hele websider ved å endre kun en fil. Denne linker vi inn i HTMLkoden. Internal bør vi bruke når vi skal gi et dokument en unik stil. Dette legger vi inn i <style>tag inne i <head>delen av HTMLsiden. Inline her mister vi mange fordeler med å ha et stilark, her blander vi innholdet med presentasjon. Denne legger vi inn i et HTMLelement, for å definere akkurat det elementet. Browser default er det stilsettet som er definert som nettleserens standard. User er når brukeren kan velge stilsett direkte i nettleseren. Rekkefølgen, eller Cascading order som det heter, er: 1. Browser default det er nettleserens standard. 2. User kan selv velge stilsett i nettleseren. 3. External style sheet det er et eksternt stilark linket inn i HTMLkoden som en ekstern CSS fil. 4. Internal style sheet det er stilen som blir definert inne i <style>taggen, innenfor <head> seksjonen i HTMLsiden. 5. Inline style det er stilen som blir definert inne i et bestemt HTML element. Her har nummer fire, inline style, høyest prioritet. Det betyr at den overstyrer stiler definert inne i <head>tagen, et eksternt stilark, og nettleserens standard stil. Vi kan si at de kopler seg sammen og blir til et nytt virtuelt stilsett ut ifra hvem som har høyest prioritet på listen ovenfor.
Oppgave E5 Hva menes med at HTML er "bakoverkompatibelt" med nettlesere (også omtalt som å støtte en "fallback"løsning)? Forklar med et lite konkret eksempel (du trenger kun skrive de kodelinjene som er relevante for å vise poenget ditt). Hvordan er det med bakoverkompatibilitet i CSS? At HTML er bakoverkompatibelt med nettlesere betyr at man skal kunne åpne et dokument av nyere HTMLstandard i en nettleser selv om nettleseren ikke helt forstår teknologien. Det vil si at vi skal kunne laste inn et HTML5 dokument i en eldre versjon av Internet Explorer uten at vi mister for mye av informasjonen. Det betyr altså at nyere versjoner av HTML vil kunne støtter (være bakoverkompatible) med eldre versjoner av HTML. Dersom nettleseren ikke kjenner igjen de nye taggene I HTML5 vil den allikevel greie å vise innholdet/informasjonen, men uten noen form for styling. <picture alt= > </picture> <source media= (minwidth: 45em) srcset= large1.jpg 1x, large2.jpg 2x > <source media= (minwidth: 18em) srcset= med1.jpg 1x, med2.jpg 2x > <source media= small1.jpg 1x, small2.jpg 2x > <img src= small1.jpg > Denne taggen er et nytt forslag W3C har kommet med, her ville en eldre versjon av en nettleser ikke skjønt den nye taggen, men den ville kunne ha vist informasjonen, siden den kjenner igjen <img>taggen. CSS har bakoverkompatibel løsning, den fungerer dersom nettleseren ikke støtter den første fonten, velger den neste font, som er i samme kategori for eksempel. p{ } fontfamily: Times New Roman, Times, serif Den leter etter nærmest fonttype som den støtter, for eksempel en annen font, men som tilhører samme fontfamilie.
Oppgave E6 Fra W3C er det foreslått en ny tagg kalt <picture>: Hva tenker du om denne taggen, behovet for den og dens muligheter for å bli en del av den endelige standarden? Ville du gjort endringer på forslaget? Jeg mener behovet for <picture>taggen er der, den vil gjøre det lettere når vi tenker tilgjengelighet med at vi kan legge inn flere source attributter. Det vil bli lettere å velge hvilken størrelse bildet skal ha basert på hva slags skjermstørrelse/skjermoppløsning den blir sett på. Srcsetattributtet gjør så vi kan bruke den i forskjellige situasjoner, som for eksempel å se den på et highresolution display, eller når vi ser den på en liten monitor. Jeg tror forslaget fra W3C absolutt har gode muligheter for å bli en del av den endelige standarden. Den har det som trengs, og baserer seg på framtiden der tilgjengelighet, og forholdet mellom store og små skjermer kommer til å spille en stor rolle innenfor webutvikling. Det jeg kan se av minuser ved denne taggen er at det er mye mer kode som skal til for å legge til et bilde, men uansett får vi en større gevinst tilbake dersom vi gjør det. Jeg både tror og håper at denne vil bli en del av den endelige standarden. Oppgave E7 Hva mener vi med box model i CSS, og hvorfor er dette så sentralt? Vi betrakter alle HTML elementer for å være bokser. I CSS bruker vi begrepet box model når vi snakker om design og layout. Box modellen går rundt alle HTML elementene, og består av margins (marginen rundt boksen som skal være fritt), borders (rammer), padding (gjennomsiktig, luft rundt innholdet), og selve innholdet. Det tillater oss å legge til borders rundt elementene, og gjør det mulig å definere luft mellom elementene, samt å påvirke avstanden til andre elementer.
Oppgave E8 Selv om historien strekker seg over forholdsvis kort tid, er det flere viktige veiskiller som har gitt oss Internett og webben i den formen vi har i dag. Hvordan kunne Internett og webben sett ut og fungert annerledes i dag dersom utviklingen hadde tatt andre veier underveis? Merk at du ikke trenger kunne historien i detalj for å svare på dette spørsmålet. Det gjelder mer å se hvilke egenskaper Internett og webben har i dag som ikke nødvendigvis burde vært slik. Vi kan knytte dette til måten mobilabonnement fungerer i dag. Det kunne blitt konkurranse mellom selskapene for å få mesteparten av befolkningen til å benytte seg av akkurat deres webservere. Selskapene kunne dermed konkurrert i å gi best mulig tilbud på både teknologi og kanskje også på pris for å være kunde av deres webserver. På lik måte som man må betale for å ha abonnement på playstation/xbox for å kunne bruke servere til å spille online. Oppgave E9 Hvilke fordeler/ulemper ville det hatt dersom en webside måtte være 100% korrekt/validert før den kunne vises av en nettleser? Tenk på standarder, teknologi, utviklere og brukere. (I de tilfellene den ikke var korrekt ville man kun sett "siden kan ikke vises".) Det ville oppstått mange problemer dersom dette hadde vært tilfelle. Det hadde gjort det veldig vanskelig for utviklere å skulle programmere uten å kunne se siden underveis. Det ville gjort det vanskelig å finne feil i designet, og hele prosessen med å utvikle en webside ville tatt mye lenger tid enn det det gjør i dag. På den positive siden hadde vi sluppet å ha websider som for eksempel arngren.net. Det ville vært mye renere og oversiktlige sider med bedre struktur. Men selv om det hadde vært ønskelig, vil selve jobben for å utvikle websiden blitt mye mer krevende. Hvordan skulle man visst at ting fungerte, dersom man ikke kunne se det underveis de aller fleste som skriver html kode, gjør som regel alltid minst en feil når de koder. Men allikevel måtte vi ha kodet ferdig websiden før de hadde funnet ut av det. For brukerne av websiden ville det vært like frustrerende som ellers å få den triste meldingen om at siden kan ikke vises. Bare at det antageligvis ville forekommet hyppigere.
Oppgave E10 Vi kan sette inn et bilde i en webside enten ved å kun bruke HTML: <img src="logo.jpg" /> eller ved CSS: <div id="logo"></div> #logo {backgroundimage:url('logo.jpg');} Hva er den praktiske forskjellen på disse metodene, og når (til hva) vil man bruke hver av metodene? Den praktiske forskjellen på de to metodene er at den ene gjøres i HTMLkoden, mens den andre gjøres i CSSstilarket. Vi bruker HTMLkoden dersom vi ønsker at bildet skal være til informasjon, mens vi gjør det i CSSstilarket dersom vi ønsker at det skal være en del av designet.