En samling spørsmål som ofte blir gjentatt i no.www.
FAQ-listen administreres av Tina Marie Holmboe [tina@htmlhelp.com]. Spørsmål, tillegg og kommentarer kan sendes til henne. Dette dokumentet kan finnes på WWW under WDG's samling av referansedokumenter - http://www.htmlhelp.com/faq/.
Versjon 2, Revisjon 02
Siste oppdatering: 17ende September, 1997.
no.www er den nyhetsgruppen i det Norske Usenet-hierarkiet som er beregnet på alskens debatt rundt fenomenet Word Wide Web; fra koding i HTML til programmering i Java. Gruppen er ikke beregnet på annonsering av kommersielle produkter, ei heller til debatt om news eller mail. For disse to emnene kan no.news.diverse samt no.mail.diverse absolutt anbefales.
Det har blitt ført en debatt rundt dette med splitting av no.www, og i den forbindelse en flytting av samme til det nye no.it.* hierarkiet. I skrivende stund finnes intet offisiellt forslag om dette, men arbeid pågår.
WWW forandrer seg fort - og ingen som idag arbeider med dette mediet kan garantere at hva som igår var riktig, også er det idag. Ingen av de som har bidratt til denne FAQ-en skal derfor lastes om det viser seg at den inneholder feil, eller at linker ikke lenger fungerer. All informasjon blir sjekket før en ny utgave av FAQ-en blir gjort tilgjengelig - men ingen garanti er gitt for at den er korrekt i det øyeblikk du leser dette.
HTML er et kunstig språk beregnet på strukturering av informasjon i sk. 'hypertext'-dokumenter. Stikk i strid med en vanlig oppfatning er ikke HTML en måte å beskrive utseendet på hjemmesider.
Ved hjelp av HTML beskriver man forskjellige strukturer i informasjon med pre-definerte 'koder'. Dersom man, for eksempel, ønsker å definere ett avsnitt i en tekst, gjøres dette slik:
<P>
tekst
</P>
Programmer beregnet på dekoding av HTML - 'User Agents' (UA), ofte 'browsere' eller 'nettlesere' - er da i stand til å presentere informasjonen i dokumentet for brukere på en passende måte. Brukeren kan vanligvis selv justere presentasjonen slik at den er tilpasset hans, eller hennes, situasjon. Informasjonen forblir den samme.
'Hypertext' er et gammelt konsept, og har i en enkel utførelse blitt benyttet i alskens bøker og oppslagsverk i mange år. Uttrykket 'se også...' er sikkert kjent av alle. En tekst med slik referanser til ytterligere informasjon er, i bunn og grunn, et 'hypertext'-dokument.
Moderne 'hypertext'-dokumenter og datamaskiner gir mulighet til, ofte med 'klikk' fra en mus, å få adgang til slik referert informasjon direkte. Det er dette brukere av WWW kjenner som 'linker'.
Mer informasjon:
Om du ikke vil gjøre det manuelt, trenger du et filter. Slike finnes det mange av, og det beste dersom du leter etter noe spesielt er å sjekke referanse-listen under.
Mer informasjon:
Punkt en er å spørre seg selv om man virkelig trenger en slik. Den tar tid, både for serveren å laste, og for brukeren å vente på. Den gir heller ikke noe riktig bilde av hvor mange som har besøkt siden din.
Det finnes selvsagt en viss nytte både for tellere og klokker, og dersom du virkelig vil/trenger en slik, finnes det to alternativ:
SSI, eller 'Server Side Include'-baserte program. Et slikt kjøres på serveren, og resultatet inkluderes i HTML-dokumentet der du bruker samme.
CGI basert. Dette fungerer på samme måte som SSI versjonen, men returnerer oftest et bilde i GIF/JPG/PNG-format. Dermed hverken teller, eller vises, telleren dersom brukeren har slått av automatisk visning av bilder.
Mer informasjon
DOCTYPE er en deklarasjon; en måte å fortelle en web-browser eller tilsvarende program hvilken versjon av HTML du har benyttet i dokumentet ditt. Både iflg. HTML 2.0 som er gjeldende standard, og den nye 3.2, er en gyldig DOCTYPE obligatorisk i et korrekt HTML dokument.
I tillegg er det DOCTYPE de fleste typer validerings-software benytter for å identifisere hvilken versjon av HTML de skal sjekke dokumenter mot. En vellykket syntaks-sjekk av HTML er følgelig avhengig av en korrekt DOCTYPE.
Noen mulige DOCTYPE-er:
Mer informasjon (inkl. DOCTYPE for Netscape og Explorer)
HTML er helt vanlig tekst, og som sådann er det bare å inkludere dette i brevet. Dog, mottageren vil se dette som tekst, og ikke som formatert HTML. Enkelte mail-systemer er istand til å vise koden omtrent som en browser ville gjøre det, men dette er ikke vanlig. Derfor: Bruk ikke HTML i stedet for vanlig tekst når du poster til no.www.
Sikker? Du vet ikke om brukeren har lydkort, om han/hun besøker siden din midt på natten - kanskje noen sover ikke så langt unna - eller lytter til musikk allerede. Det blir av mange sett på som temmelig uhøflig å bare spille musikk slik uten videre.
Den beste metoden, og den som anbefales av musikere aktive på WWW, er å putte inn en link til lydfilen, slik:
<A HREF="sound.wav">Hear me speak! (5 kB WAV)</A>
Om du nå allikevel insisterer, så finnes det 'hack' som tillater både Netscape og Explorer å avspille musikk i bakgrunnen. <i>Selvsagt<i> virker ikke samme hakk for begge, men følgende burde hjelpe:
<EMBED SRC="sound.mid" AUTOSTART="true" LOOP="true" HIDDEN="true">
<NOEMBED>
<BGSOUND SRC="sound.mid" AUTOSTART="true" LOOP="infinite">
</NOEMBED>
Det gjør du ikke. Det er kun en vanlig email-adresse som kan benyttes inni en 'mailto:'. Enkelte browsere, blant dem Lynx, støtter også:
<a href="mailto:..." title="subject her">...</a>
Noen få browsere, Lynx 2.5(og senere), samt Netscape 3.0(og senere), støtter konstruksjonen
<a href="mailto:adresse@domain?Subject:Mitt subject..."> ... </a>
men: et brev som sendes via en slik link vil aldri komme frem til mottager dersom brukeren benytter en hvilken som helst annen browser.
Det er også blitt foreslått å benytte følgende konstruksjon:
"mailto:whomever@whereever.com (my subject)"
Dog er dette en ugyldig URL, og det er bare enkelte browsere som støtter denne metoden. Som konklusjon finnes det kun en ikke-CGI basert metode som unngår tap av post: bruk av TITLE attributtet til A. CGI er å anbefale for slike oppgaver.
Dessverre er ikke Netscape og Explorer helt enige om syntaksen til FRAMES.
Spesielt virker det som om den ene tillater FRAMESET innenfor
BODY, mens den andre ikke gjør det. Begge tillater
dokumenter med denne strukturen:
<html>
<head>
<TITLE> Tittel here </TITLE>
</head>
<FRAMESET ROWS="10%,*">
<FRAME SRC="topframe.html">
<FRAME SRC="bottomframe.html">
<NOFRAMES>
<BODY>
</BODY>
</NOFRAMES>
</FRAMESET>
</HTML>
Mer informasjon:
Først: er dette virkelig en god ide? Dermed blir det vanskelig for brukerne å vite hva som er en link, og hva som ikke er det. Dersom du fremdeles vil fjerne 'rammen', er koden for å gjøre dette:
<img src="..." alt="..." height="..." width="..." BORDER="0">
^^^^^^^^^^
Nei - bildene må alle flyttes - byte for byte - over nettverket uansett om du har spesifisèrt hvilken høyde og bredde de har. Derimot finnes det flere browsere som utnytter denne informasjonen til å sette av plass på skjermen til bildene. På denne måten kan browseren begynne å vise frem ev. tekst med det samme. Dersom du ikke oppgir bredde/høyde, må samme browser vente til alle, og hele, bildene er overført før den kan begynne å 'tegne opp' siden.
Enkelt browsere, spesielt da Netscape, setter av plass til bildene selv om 'image-loading' er av. Dette virker til å begynne med som en god løsning. Dog, Netscape viser også i slike tilfeller frem ALT-teksten til bildet, og er teksten da lenger enn boksen, blir den -teksten- kuttet.
For det første finnes det en begrenset mengde av sk. protokoller som kan benyttes i hypertext-linker. Hver enkelt av disse har i tur forskjellige syntaks og struktur.
Detaljer om disse protokollene kan du finne i RFC 1738. Der defineres følgende protokoller:
Det beste er å benytte et CGI-skript for å prosessere disse brevene, men enkelte browsere støtter også følgende:
<FORM ACTION="mailto: ... " ENCTYPE="text/plain">
Det finnes mer enn en måte å gjøre dette på, men som så meget annet som ikke er standard, er det ikke alle browsere som støtter alle metoder. Dette er det 'tryggeste':
<FRAMESET ... BORDER="0" FRAMEBORDER="0" FRAMESPACING="0">
Begge deler er tillatt etter HTML-spesifikasjonen, men prosenter er absolutt å foretrekke. Dersom bredden er spesifisert slik kan browseren tilpassen tabellens størrelse etter det vinduet den kjører i.
Det finnes, med 'rå' HTML, ingen garantert metode for dette. Du kan benytte følgende, men det er ikke en løsning som er garantert å virke for alle browsere:
<META HTTP-EQUIV="Refresh" CONTENT="x; URL=new.URL">
Ikke alle browsere, som sagt, støtter dette. Legg derfor også ved
en vanlig href til samme side, som kan benyttes dersom
overstående ikke virker.
Med SSI - Server Side Includes - er dette enkelt:
<!--#include file="annenfil.html" -->
Standard tegnsett for HTML-dokumenter er en delmengde av iso-8859-1, som spesifisert i HTML 2.0. En liste av tegn finner du også hos WDG. Benytt kun tegn fra denne delmengden direkte i HTML-dokumenter.
Dersom du er helt sikker på at den plattformen / det OS'et / den editoren du benytter bruker ISO-8859-1, er det enkleste og beste å skrive spesialtegn direkte.
Om du ikke kan bruke ISO-8859-1, er både å,
å eller å riktig, men endel
browsere forstår ikke å-syntaksen. Kan du ikke
bruke spesialtegn direkte, skriv dem derfor som &#siffer;
Mer informasjon:
Det finnes per idag ingen enkel mulighet til dette. Det fantes slike muligheter med HTML 3.0-standarden, men da denne ikke lenger utvikles, og ei heller støttes av særlig mange browsere, er det ingen god løsning.
Det du kan gjøre er å benytte små GIF/JPG/PNG-bilder av de aktuelle symbolene. Dette er ikke en perfekt løsning, men den eneste mulige for øyeblikket.
Her ville jeg absolutt anbefale latex2html som selv genererer masse små GIF-er. Jeg har ikke benyttet dette noe særlig selv (ennå), men se f.eks. på http://www.ifi.uio.no/%7Ejonhaug/latex/gif-test/gif-test.html Dette må være en av de beste metodene å utvikle kompliserte html-dokumenter med mye matematikk. Peker til info om latex2html finner du her: http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/. Ulempen med dette er jo selvsagt at for de som bruker en browser med en annen font-størrelse (enn 12pt?) blir utseendet litt rart, men det er fortsatt leselig. jh
Liste over steder med slike bilder følger.
I korthet ser en URL slik ut:
<scheme>:<scheme-specific-part>
hvor <scheme> står for den protokollen som skal
benyttes, og hvor <scheme-specific-part> er de data som samme
protokoll trenger for å gjøre sin jobb. Navnet på protokollen
kan bestå kun av bokstavene 'a' til 'z', tall, samt '+', '-', og '.'.
Disse navnene er også 'case insensitive', hvilket betyr at
HTTP er identisk med http.
I selve de data som benyttes, dvs. <scheme-specific-part>, kan kun tegnsettet US-ASCII brukes; alle tegn som ikke forekommer der må kodes. Det samme gjelder alle sk. 'utrygge' tegn, dvs. disse:
< > " # % { } | \ ^ ~ [ ] `
I tillegg til ikke-US-ASCII og 'uttrygge' tegn, må alle slike tegn kodes som er avsatt til annet bruk. Disse er:
; /? : @ = &
Skal du derfor bruke, i selve URL-en, et av de overnevnte 'uttrygge' eller reserverte tegn, må disse kodes.
Koding foregår ved at man tar tegnets hexadesimale verdi, eksempelvis
7E for ~, og legger til en % foran, slik: %7E
Husk, til sist, på at dersom det du refererer med URL-en ikke er et dokument, må du avslutt URL-en med '/'. F.eks. er følgende ikke korrekt:
ftp://ftp.unit.no
mens dette derimot er riktig:
ftp://ftp.unit.no/
Mer informasjon:
Det kan du ikke - dersom en browser skal kunne vise frem siden din, må den først få tilsendt koden. Dermed har leseren allerede en kopi, og kan titte på den i ro & mak.
Under konstruksjon.
Begge er objektbaserte språk, men egner seg best på ulike områder. Mens java kan kompileres ned til bytekode, er javascript fullt ut et tolket språk. Konsekvensen av det er at java hviler på typedeklarerte metoder, mens javascript er såkalt 'utypet' eller 'løst typet'.
Poenget med javascript er tosidig. For det første kan en på bruker- eller klientsiden bygge opp dynamiske egenskaper og funksjonaliteter ved at man integrerer skriptet i en eventuell html-kode. Man kan da se på skriptet som en del av web-dokumentet. Og for det andre kan javascript benyttes på serversiden som alternativ for oppbygging av CGI (se evt. spm. om forkortelser).
Java, derimot, har et mer generelt preg. Java er et uavhengig språk (stand-alone). Derimot tilbys også her web-integrasjon, men forskjellen fra javascript, imidlertid, er at nedlastbare objekter som benyttes i forbindelse med HTTP er prekompilerte (applets) og vil ikke være en del av HTML-dokumentet.
årsaken til en slik integrasjon ligger i et "skreddersydd" miljø, snarere enn at det er en generell egenskap av java. Derfor er det rimelig å se på javascripts web-integrasjon som "regelen", mens det i javas tilfelle er "unntaket".
Begge språk har i websammenheng restriksjoner m.h.t. ressurstilgang (se evt. spm. om sikkerhet).
Mer informasjon:
Mer informasjon:
For det første: det finnes ingen mulighet for å skrive en 'WYSIWYG'-, eller 'WhatYouSeeIsWhatYouGet' editor for HTML. HTML er beregnet på å gi et dokument en viss struktur, og ikke et visst utseende. Det er umulig for en editor å forutsi hvordan et dokument kommer til å vises frem hos brukeren.
Dog; det finnes en rekke editorer som er til mer eller mindre nytte ved produksjon av HTML. Her er noen linker til steder hvor du kan finne slike.
Kort svar: alle. Du kan ikke på forhånd vite noe som helst om hva slags oppløsning, fargedyp eller generelt utstyr en bruker har. Dermed vil ett design som er avhengig av spesifikt utstyr alltid bomme på noen.
Heldigvis er HTML uavhengig av slike ting - siden dette er et språk for å 'bygge inn' en struktur i dokumenter, og ikke utseende eller layout. Noen regler å å ha i tankene:
Dersom du ønsker å utnytte browser-spesifikke 'tricks', så lønner det seg å undersøke hvorvidt disse triksene 'går istykker' - eller 'degraderer' på en brukbar måte i browsere som ikke støtter dem.
Eksempelvis så er det slik at browsere som kun støtter HTML 2.0 ikke har støtte for tabeller. Derimot vil en slik browser alltid vise frem innholdet mellom <TABLE> og </TABLE>. Ved å plassere en <BR> i den siste tabell-cellen på hver rad, vil informasjonen i tabellen komme frem også i gamle browsere.
Det gjelder altså å vite hvilke triks som fungerer, og hvilke som kan skape kaos. Uansett er browser-spesifikke triks en uting som bør utnyttes så lite som overhodet mulig. Dette gjelder også for proprietære løsninger som Java/Shockwave/ActiveX.
Til dette finnes det ganske mange verktøy. Her følger en liste over de mest kjente, samt pekere til sider med detalj-beskrivelse av teknikken bak.
Mer informasjon:
CGI (Common Gateway Interface) er et enkelt grensesnitt for kommunikasjon mellom webservere og programmer. I stedet for å få opp en html-side, kan man sette opp serveren slik at den starter et program som f.eks. returnerer HTML.
Ulempen med å bruke CGI er at webserveren må starte opp programmet hver gang, og dette krever mye av maskinen i forhold til å bare levere ut en fil.
Mer informasjon:
JavaScript er et enkelt objekt-orientert språk som primært er beregnet på å kjøre i browsere. Typiske bruksområder er å sjekke input fra forms, og å skreddersy sider for spesielle maskiner/browsere.
Til tross for navnet er ikke JavaScript en "forenklet utgave" av Java, men JavaScript kan brukes som et bindeledd mellom Java-applets og HTML.
Mer informasjon:
Mer informasjon:
Det kan være flere årsaker til dette - blant de vanligste er
På en av to måter: enten med et CGI-skript som ber om/sjekker passord og sender en side ut til brukeren, eller ved å bruke en sk. '.htaccess'-fil. Mer informasjon om dette kan du finne på http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html
Les gruppen no.svar. Der får du svar.
Mer informasjon:
'Cookies' er, for å sitere Netscape, en generell mekanisme som servere kan benytte for å lagre, og hente tilbake, informasjon fra klient-siden i en oppkobling.
Mer informasjon:
Dette er listen over mennesker som har bidratt til denne FAQ-en, med inspirasjon, støtte, teknisk kunnskap; med svar og med spørsmål.
I de tilfeller der større deler tekst er bidratt med, er disse lagt til i sin helhet, og uten editering fra min side.
© Tina Marie Holmboe, 1997.