Gå til innhold

Mulig å bestemme linkutseende (a:link...) for div-er?

Anterialis

Anbefalte innlegg

Anterialis

Anterialis

Skrevet
Skrevet (endret)

Er dette mulig?

Er mange år siden jeg holdt på med dette, og nå har jeg blitt litt interessert igjen...

 

Er denne koden lovlig, og funker den?

#validcss a:visited
	{
	text-decoration: none;
	}

 

I htm-documentet bruker jeg da <div id="validcss"> Funker dette?

Gi meg gjerne link til sider hvor det står mer om bruken av ikke-globale a:link ol.

 

Tingen er det at jeg har to bilder (med link) i en egen div. Jeg vil ikke at disse bildene skal få stygg blå ring rundt seg etter at man har trykka på linken. Altså en sånn a:visit ring :s Dette vil jeg fjerne for begge bildene, og lurer på om jeg kan sette denne coden for divven.

 

På forhånd takk =)

Endret av w3p
Lenke til kommentar

Videoannonse

Videoannonse
Annonse
Haraldson

Haraldson

Skrevet
Skrevet

Høh? Er ikke helt sikker på hva du vil, men jeg prøver likevel;

 

Hvis du vil at noe annet enn lenka skal forandre seg når lenka er besøkt, bør nok dette være elementer inni selve <a>-elementet. For eksempel to <span>-elementer med klassenavn som du kaller på med a:visited span.foran etc. Så kan du heller sette bakgrunner på disse <span>-elementene som du skjuler med background-position ved :link og viser ved :active eller noe. Er jeg inne på noe?

Lenke til kommentar
Anterialis

Anterialis

Skrevet
  • Forfatter
Skrevet

Det kan godt hende du er inne på det, men har ikke brukt <span> før (dårlig, i know), så vetke helt hva du mener.

 

Men det _jeg_ mener er, at man har jo globale settings for linker, det skriver man jo som a:link {} og a:hover {} ol. Dette funker jo på alle linker. Men om jeg vil endre utseendet til linker på en spesiell del av siden, kan jeg gjøre dette i en <div>? Jeg vet jeg kan skrive feks 

h2 a:link {}

 

og sette linker innenfor <h2> tagger utenom de globale linksettingsene (som er satt i a:link). Men kan jeg sette egne linkpreferanser for <div>-er?

 

skjønner? =)

Lenke til kommentar
Haraldson

Haraldson

Skrevet
Skrevet

Ja, det går på helt grunnleggende DOM i CSS. Et element inni et annet angis slik du skriver.

 

element1 element2 {
element1#id element2.klasse {
#id .klasse {

etc. Det elementet lengst til venstre, uavhengig av om det angis med element-/node-navn, klasse eller id eller med en annen type selektor, er ett eller flere nivåer over i DOM-en enn det som står nest lengst til venstre etc.

Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet
Er dette mulig?

Er mange år siden jeg holdt på med dette, og nå har jeg blitt litt interessert igjen...

 

Er denne koden lovlig, og funker den?

#validcss a:visited
	{
	text-decoration: none;
	}

 

I htm-documentet bruker jeg da <div id="validcss"> Funker dette?

Gi meg gjerne link til sider hvor det står mer om bruken av ikke-globale a:link ol.

 

Tingen er det at jeg har to bilder (med link) i en egen div. Jeg vil ikke at disse bildene skal få stygg blå ring rundt seg etter at man har trykka på linken. Altså en sånn a:visit ring :s Dette vil jeg fjerne for begge bildene, og lurer på om jeg kan sette denne coden for divven.

 

På forhånd takk =)

 

Dette omtales i hovedsak i to dokumenter:

http://www.w3.org/TR/CSS21/selector.html

http://www.w3.org/TR/css3-selectors/

 

CSS2.1 er mest interessant:

"E:link, E:visited

Matches element E if E is the source anchor of a hyperlink of which the target is not yet visited (:link) or already visited (:visited)."

 

Under XHTML2.0 kan man tilordne nesten alle elementer en lenke. Derav det kjeitete og rare språket.

 

Under HTML4.01 så kan kun a-elementet tilordnes en lenke, og siden det da kun kan være kilden til en lenke, så vil du ikke kunne oppnå den effekten du søker under CSS2.1

http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes

 

En annen ting du skal vokte deg for er å lage klasser for alt mulig rart. Du burde heller jobbe med informasjonsstruktur slik at den passer til utstrakt bruk av selectors. Da kan du eksterm forvandle en side bare ved å endre på stilark.

 

Det er altfor tidlig å benytte DOM nøsting i stilark, når ikke CSS2.1 er implementert fullstendig ennå i for eks. Opera 9.27. Jeg fant heller ikke slik nøsting omtalt i selector delen for CSS3, mulig jeg har oversett noe?

 

Frode

Lenke til kommentar
Haraldson

Haraldson

Skrevet
Skrevet

Hva er det egentlig du mener, Frode? Når jeg nevnte DOM, så mente jeg akkurat DOM, som i Document Object Model. CSS benytter jo DOM-en i aller høyeste grad når du bygger opp selektorer, slik jeg beskrev.

#hei p betyr nettopp at et gitt <p>-element omsluttes av element med id #hei. Dette er jo nettopp DOM.

 

Hvorfor i all verden skal man vokte seg for å lage klasser?

Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet
Hva er det egentlig du mener, Frode? Når jeg nevnte DOM, så mente jeg akkurat DOM, som i Document Object Model. CSS benytter jo DOM-en i aller høyeste grad når du bygger opp selektorer, slik jeg beskrev.

#hei p betyr nettopp at et gitt <p>-element omsluttes av element med id #hei. Dette er jo nettopp DOM.

 

Hvorfor i all verden skal man vokte seg for å lage klasser?

 

Jeg tror jeg rett og slett missforstod innlegget ditt da jeg leste det som at du nøstet med paranteser "{". Noe jeg ikke akkurat forsod helt, da jeg ikke er noen spesialist på DOM, enda. Beklager det.

 

Jeg mener man skal vokte seg mot å lage for mange unødvendige klasser, særlig klasser man blander inn på innholdsnivå. I det øyeblikket nth-child(), "<", og "+" får støtte under IE blir verden aldri den samme igjen.

 

Da vil man benytte en liten håndfull med klasser og selectors i henhold til disse klassene. Dette vil tvinge frem ett fokus på informasjonsstruktur, da fordelene ved å designe slik er enorme.

 

Jeg mener at man ikke burde lete etter funksjonalitet som ikke er planlagt støttet under CSS3 nå, og at man ved å benytte ett minimum av klasser langt på vei kan "simmulere" hva som kommer allerede i dag.

 

Jeg har lagt ut noen layout eksempler i denne tråden:

https://www.diskusjon.no/index.php?session=...&p=11104219

 

I det første eksemplet vil du egentlig ikke trenge en eneste klasse i fremtiden, litt mer i tvil om det er hensiktsmessig med eksempel nummer to.

 

Hvis du har en klasse til å identifisere innhold, så kan du formatere resten av innholdet ved hjelp av selectors utifra den klassen. Du må bare jobbe med hvordan du strukturerer innholdet.

 

eks:

div.navigering ul{ display: inline-block;}

div.navigering ul li.aktiv{ font-weight: bold;}

div.artikkel p{padding:10px;}

div.footer p{font-size:10px;}

div.reklame {z-index:10;}

 

Ved å holde bruken av klasser på ett minimum så vil slike design kunne benyttes med moderne fremtidig CSS3, og du vil ha mange års forsprang på resten av bransjen. Dette er en drøm å jobbe med.

 

Det medfører av og til at du må skrinlegge fancy ting for IE, mens FF, Safari, og Opera snart støtter CSS3 tilstrekkelig. Man har jo alltids den billige løsnigen med klasse kaos og javascript for IE. De som må betale for slikt vet jo hva det koster.

 

Frode

Lenke til kommentar
Haraldson

Haraldson

Skrevet
Skrevet

Ja, jo, men slik formatering du snakker om er helt, fullstendig normalt den dag i dag (for de som kan et minimum), og det er bare de færreste som eksempelvis bruker li.menu-item istedenfor #menu li.

 

For øvrig er det mye mindre semantisk og vanskeligere å lese eksempelet ditt enn det kunne ha vært om du brukte klasser istedenfor. body div div div sier veldig lite og er veldig lite spesifik kode, noe som kan føre til problemer med hvilke egenskaper som gjør seg gjeldende når siden skal rendres. body .outer-wrap .inner-wrap .wrap (beste eksemplene jeg kom på i farta) sier mye mer om divenes funksjon og hvorfor de er der, og hele selektorens verdi har gått fra 4 til 31.

 

 

Når det gjelder avanserte selektorer, like gjerne attributt-selektorer for å bruke det som eksempel, så vil dette øke fleksibiliteten, men det vil aldri kunne gjøre bruken av klasser overflødig, tror jeg.

Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet
Ja, jo, men slik formatering du snakker om er helt, fullstendig normalt den dag i dag (for de som kan et minimum), og det er bare de færreste som eksempelvis bruker li.menu-item istedenfor #menu li.

 

For øvrig er det mye mindre semantisk og vanskeligere å lese eksempelet ditt enn det kunne ha vært om du brukte klasser istedenfor. body div div div sier veldig lite og er veldig lite spesifik kode, noe som kan føre til problemer med hvilke egenskaper som gjør seg gjeldende når siden skal rendres. body .outer-wrap .inner-wrap .wrap (beste eksemplene jeg kom på i farta) sier mye mer om divenes funksjon og hvorfor de er der, og hele selektorens verdi har gått fra 4 til 31.

 

 

Når det gjelder avanserte selektorer, like gjerne attributt-selektorer for å bruke det som eksempel, så vil dette øke fleksibiliteten, men det vil aldri kunne gjøre bruken av klasser overflødig, tror jeg.

 

Det er litt vanskelig å gi ett fullverdig eksempel på hva jeg mener, uten å legge veldig mye arbeid ned i det. Det tror jeg ikke jeg gidder her.

 

Men body div div div er satt for å nullstille effekten av body div div, da IE ikke støtter child kombinator. Den sier en hel del. Mulig den ble overflødig, men nullstilling er poenget med den.

 

Jeg er ikke tilhenger av å gi div en klasse som "wrap", da elementet ikke nødvendigvis vil spille en slik rolle under forskjellige stilark. Jeg skal gi deg rett i at det er det som virker mest naturlig sånn umiddelbart, men ved en liten endring på eksemplene mine så kunne man ha benyttet nøstede floats eller tabeller om hverandre mot samme markup, og da finnes det ikke passende rolle navn, da rollene i stilarkene er helt forskjellig.

 

Denne teknikken stiller store krav til at man samler egenskapene sånn som jeg har gjort, for da har mann full kontroll på hvordan alle egenskaper da de håndteres på en plass. Det er snarere ett argument mot kompliserte selectors å benytte masse attributt selectors. Merk at jeg kun har benyttet arv combinator og svært enkle klasser, noe som ikke vil gi slike uoversiktelige konflikter som du referer til.

 

Dette er den skolen jeg jobber etter, men det finnes klart flere måter å løse layout på. Hva som passer best er ofte særs avhengig av designmålene for det man jobber med.

 

For innhold er jeg derimot ikke til å rikke. Hvis du har en gjennomtenkt informasjonsstruktur så er det å skille informasjon fra formatering en lek med CSS3 selectors. Ved å begrense friheten på strukturen til informasjonen, så eksploderer friheten til formatering. Pandoras eske er å slippe til for mye strukturell frihet i informasjonen.

 

Jeg er fullstendig klar over at man kan bruke attributter til å definere hvilken elementer som påvirkes, men jeg har enda ikke sett ett fornuftig eksempel på dette utenom klasse og id.

 

I definisjonen benyttes css til å endre innholdet på en side ved å filtrere etter språk. Da benyttes ikke css til formatering lenger, men til å endre informasjonen. Det blir like galt som å benytte tabeller til formatering, bare omvendt.

 

Jeg er høyst åpen for gode eksempler på slik bruk, hvis du har noen.

 

Frode

Lenke til kommentar
Haraldson

Haraldson

Skrevet
Skrevet (endret)

Jeg mister bare tråden i de lange innleggene dine, jeg, så jeg er ikke sikker på hva du spør om.

 

Eksempel på attributt-selektor er for eksempel hvis det er interessant å skille mellom eksterne og interne lenker, hvor sistnevnte benytter relativ lenking. Syntaksen gidder jeg ikke å google opp, men et par eksempelet kan jeg jo skrive fort;

 

a[href="http://^"] { /* CSS for eksterne lenker her */ }
input[type="submit"] { /* CSS for submit-knapper.. */ }

 

 

Jeg er for øvrig ingen fan av hverken måten du bare hiver inn ekstra diver bare for å få ekstra nivåer i DOM-en (da bør de som jeg skrev tidligere i det minste ha en semantisk verdi eksempelvis gitt i form av et klassenavn), eller hvordan du grupperer egenskapene i CSS-en. For meg blir det veldig mye mer rotete enn om alle aktuelle verdier står under én selektor. Nå er jeg vant til å jobbe sammen med andre utviklere hver dag, og ofte handler jobben min også om å endre eller rette på kode andre har skrevet, og da ville din kode vært et sant mareritt å jobbe med.

 

Det skader ikke å være spesifikk i koden din, er det så store sprik lønner det seg som regel å opprette flere forskjellige malverk med egen HTML og tilhørende CSS. I alle fall hvis andre skal jobbe med koden din.

Endret av Haraldson
Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet
Jeg mister bare tråden i de lange innleggene dine, jeg, så jeg er ikke sikker på hva du spør om.

 

Eksempel på attributt-selektor er for eksempel hvis det er interessant å skille mellom eksterne og interne lenker, hvor sistnevnte benytter relativ lenking. Syntaksen gidder jeg ikke å google opp, men et par eksempelet kan jeg jo skrive fort;

 

a[href="http://^"] { /* CSS for eksterne lenker her */ }
input[type="submit"] { /* CSS for submit-knapper.. */ }

 

 

Jeg er for øvrig ingen fan av hverken måten du bare hiver inn ekstra diver bare for å få ekstra nivåer i DOM-en (da bør de som jeg skrev tidligere i det minste ha en semantisk verdi eksempelvis gitt i form av et klassenavn), eller hvordan du grupperer egenskapene i CSS-en. For meg blir det veldig mye mer rotete enn om alle aktuelle verdier står under én selektor. Nå er jeg vant til å jobbe sammen med andre utviklere hver dag, og ofte handler jobben min også om å endre eller rette på kode andre har skrevet, og da ville din kode vært et sant mareritt å jobbe med.

 

Det skader ikke å være spesifikk i koden din, er det så store sprik lønner det seg som regel å opprette flere forskjellige malverk med egen HTML og tilhørende CSS. I alle fall hvis andre skal jobbe med koden din.

 

Jeg har forstått at du ikke forstår teorien bak arbeidet mitt, men jeg forstår ditt ståsted og hva du sier. Jeg kan jobbe på klassisk hvis hvis det er ett designkrav, men det blir en reise tilbake i tid og utvikling.

 

Ellers har du klart å arrestere meg på input elementet! Jeg burde nok revurdere min holdning til type attributtet. Takk skal du ha!

 

For ordens skyld så "hiver jeg ikke bare inn diver". Jeg har ikke så mye som en eneste meningsløs div. Alle div-elementene jeg har benyttet har en klar baktanke og en presist spesifisert rolle i ett stilark, noe som er delvis omhandlet i teksten i markup. Du må lese formaterings rollen ut av stilarket, og innholdsrollen ut av markup. Det må være en hvis mengde med nøstende div-elementer for å kunne bruke bestemte layout-teknikker.

 

Hvis jeg forstår deg riktig så mener du at få utviklere vil forstå grunntankene i den koden jeg har lagt ut, samt at de ikke vil forstå teorien bak den?

 

Frode

Lenke til kommentar
Haraldson

Haraldson

Skrevet
Skrevet

For det første vil det ta ekstra tid å sette seg inn i hvordan teknikken er ment å fungere ut fra HTML-en.

 

For det andre vil det gå mange ekstra sekunder når en utvikler søker gjennom CSS-en etter en gitt selektor når denne samme selektoren gjengis x antall ganger nedover.

 

Og, for det tredje, vil selektorene dine alltid være kronisk 'svake' (se lenke to innlegg opp) og du vil ikke like lett kunne overstyre CSS arvet fra andre selektorer.

 

 

Nå benytter jeg meg ofte av nøstede diver selv (ofte er det PNG inni bildet, noe som gjør den teknikken ubrukelig siden ting skal PNG-fikses for IE6, hvor grafikken skaleres til elementets dimensjoner). For layouter som eksempelvis må løses med tre bilder, ett for avrundinger i toppen, ett for repeterende rammer i y-retning og ett for avrundinger i bunnen, er nøstede diver alltid å foretrekke (hvis ikke delvis gjennomsiktig grafikk, altså) - Da vil den innerste diven med innhold alltid sørge for at de to utenfor skalerer seg til størrelse, basert på det samme innholdet, slik at grafikkene alltid strekker seg så langt de trenger og avrundingene plasserer seg riktig.

 

Jeg vet ikke om det er av sånne grunner du bruker nøstede diver (jeg forvirres av tabellreferansene, som jeg ikke ser som noe mål i seg selv å simulere med diver og CSS) eller om du bruker det til noe annet.

Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet

Vi har nå kommet til kjernen av forutsetningen for denne teknikken: Informasjonsdesign.

 

Man må skille mellom layout og innhold i både css og markup. Man definerer strukturen på innhold stramt og presist, og begrenser hva som er lov. Layout er i sin natur friere og ikke hensiktsmessig å strukturere på samme måte som innhold, men det er mulig å utarbeide retningslinjer for forskjellige teknikker også her.

 

En designer må derfor alltid bruke tid på å bli kjent med layout strukturen. Han må også sette seg inn i strukturen på innholdet.

 

Jeg er tilhenger av at man definerer en bregenset mengde med strukturer for innhold, og gjenbruker disse. Da kjenner man innholdstrukturen og kan gjenbruke kode. Det å definere stramme men tilstrekkelige fleksible strukturer er helt kritisk, og særs vanskelig.

 

Når det gjelder layout, så kan man for eks. benytte kun nøstede floats på en bestemt måte eller kun visuelle tabeller på en bestemt måte. Man kan lage ett rammeverk for hvordan dette skal implementeres, og følger man dette rammeverket så tar det sekunder å kjenne igjen og forstå koden.

 

Hvis man mangler innarbeidede teknikker og ett innarbeidet rammeverk slik at man jobber på ulike måter, så blir ting vanskelig ja. Jeg er han som lager rammeverket, definerer det, forstår hvorfor vi har det, og er han som må lære opp de andre.

 

Dette er ikke vanskelig å lære eller jobbe mot, det er egentlig overraskende lett, i motsetning til den typiske sausen man finner.

 

Mange programere er pragmatiske, og det kan fort oppleves ubehagelig for dem å stappes inn i en tilsynelatende kodekvern som dette. Jeg skisserer noe som er svært systematisk, noe som ikke nødvendigvis passer en analytisk kultur eller analytiske individer.

 

Denne arbeidsmåten vil endre sosial rang og status blandt utviklerne, og mange vil miste sin staus som spesialist. Mange vil oppleve at sine kunnskaper og sine arbeidsmåter forkastes.

 

Det er de invendingene som bekymrer meg mest, og er de som er vanskeligst å løse. De sosiale.

 

Teknisk er dette planke.

 

Frode

Lenke til kommentar
Anterialis

Anterialis

Skrevet
  • Forfatter
Skrevet

Dette er veldig interessat alts, synd jeg ikke forstår halvparten :p Men dere virker jo ganske så habile begge to, at jeg spør om et spørsmål til, selv om jeg kanskje burde opprettet ny tråd. Jeg kodet litt (html + litt css, og marginalt php (les: php include ol)), og har fått litt sansen igjen. Men ettersom jeg aldri har vært noe flink på design, vil jeg i alle fall bli flink til å skrive rene koder (xHTML gjerne), og lære meg mer om css. Jeg vet at w3scools har noen fine guider på dette, men er det andre steder på nett som kan lære meg gode vanner hva html, css (og php) gjelder?

 

=)

Lenke til kommentar
FrodeNilsen

FrodeNilsen

Skrevet
Skrevet
Dette er veldig interessat alts, synd jeg ikke forstår halvparten :p Men dere virker jo ganske så habile begge to, at jeg spør om et spørsmål til, selv om jeg kanskje burde opprettet ny tråd. Jeg kodet litt (html + litt css, og marginalt php (les: php include ol)), og har fått litt sansen igjen. Men ettersom jeg aldri har vært noe flink på design, vil jeg i alle fall bli flink til å skrive rene koder (xHTML gjerne), og lære meg mer om css. Jeg vet at w3scools har noen fine guider på dette, men er det andre steder på nett som kan lære meg gode vanner hva html, css (og php) gjelder?

 

=)

 

htmldog.com får mange godt i gang uten å villede dem for mye.

 

Du har selv tatt opp ett problem jeg ikke tror du finner så mange gode svar på, med mindre du forholder deg til definisjonen av språket. Definisjonene er ganske folkelig skrevet, og er pr definisjon riktige.

 

Det er ingenting galt i å starte med htmldog, men du gjør mer riktig hvis du kommer deg over til definisjonene så fort som mulig. Det står temmelig presist formulert i definisjonene hva språkene er ment å gjøre og hva som er gode vaner. Du trenger ikke forstå alt: Hopp over det du ikke forstår. Når du trenger hjelp slår du bare problemet opp, og vips, så forstår du en del du ikke hadde forutsetninger til å forstå før.

 

Problemet er at få utviklere leser definisjonen, men leser istedenfor alle mulige rare artikler rundt om på nettet. De kjenner knapt definisjonen. Det gir ganske mange rare utslag.

 

Se lenke tidligere i tråden eller gå til http://www.w3.org

 

Frode

Lenke til kommentar
JohndoeMAKT

JohndoeMAKT

Skrevet
Skrevet (endret)

Til trådstarter, ja og jeg anbefaler hvertfall at du skriver på den måten.

 

Men Frode, benytter du deg av JavaScript for DOM-modifisering? Da er det er stort behov for ID- og class-attributter. Jeg ser heller ikke grunnen din for å ikke ha klasse-attributter og slikt og IMO er din kode gal semantisk sett. HTML/XML er ikke for å contain/inneholde content/informasjon men for å beskrive content. En navnløs <ul> når informasjonen denne inneholder har en navngibar funksjon og den er eneste av sin sort er slik jeg ser det feil. Da skal den markeres opp som f.eks id="menu" og som Haraldson har nevnt er slike selectorer mye raskere. Jeg er for å beskrive content og å bruke ID der noe er unikt og class der det er flere like elementer. Jeg bruker ikke generiske klasser som .float-left.text-bold og jeg koder CSS så spesifikt som mulig opp mot nærmeste unike element. Her er litt kode fra en prototype jeg nylig lagde. Her har jeg bare kopiert en DIV fra midt på siden og tilhørende CSS men om du kopierer dette verbatimt hvor som helst inn i et hvilket som helst annet HTML-dokument vil den fortsatt beholde det aller meste av sin visuelle struktur fordi markup og CSS er skrevet for å beskrive mot enhetsnivå ( altså, "dette er en kalender" ) uten å være skrevet relativt til rotnoden. Dersom du i ditt system skulle ha flyttet kalenderen til en annen plass i DOM måtte du ha omskrevet mye kode uten at det nødvendigvis er lett å se effektene av endringene. Jeg vet at all CSS-kode som begynner med #calendar eller #appointment-editor eller #print-alternatives eller #day-wrapper eller #footer eller #header påvirker bare sine enheter og at all CSS starter med en funksjonsbeskrivende id.

 

Mine to øre, :)

 

Etter å ha lest det du skriver uten kode og relatere til ser jeg at kode bør legges ved for å beskrive skolen du tilhører.

Klikk for å se/fjerne innholdet nedenfor

<div id="calendar">
				<a href="" id="calendar-navigate-back"></a>
				<h2>Mai 2008</h2>
				<a href="" id="calendar-navigate-forward"></a>
				<div class="calendar" id="month-calendar">
					<div class="week">
						<a href="" class="day number">
							<span>Uke 10</span>
						</a>
						<a href="" class="day hidden">
							<span></span>
						</a>
						<a href="" class="day hidden">
							<span></span>
						</a>
						<a href="" class="day hidden">
							<span></span>
						</a>
						<a href="" class="day">
							<span>01</span>
						</a>
						<a href="" class="day">
							<span>02</span>
						</a>
						<div class="clearer"></div>				
					</div>
					<div class="week">
						<a href="" class="day number">
							<span>Uke 11</span>
						</a>
						<a href="" class="day off">
							<span>05</span>
						</a>
						<a href="" class="day">
							<span>06</span>
						</a>
						<a href="" class="day">
							<span>07</span>
						</a>
						<a href="" class="day">
							<span>08</span>
						</a>
						<a href="" class="day">
							<span>09</span>
						</a>
						<div class="clearer"></div>					
					</div>
					<div class="week active">
						<a href="" class="day number">
							<span>Uke 12</span>
						</a>
						<a href="" class="day">
							<span>12</span>
						</a>
						<a href="" class="day">
							<span>13</span>
						</a>
						<a href="" class="day active">
							<span>14</span>
						</a>
						<a href="" class="day">
							<span>15</span>
						</a>
						<a href="" class="day">
							<span>16</span>
						</a>	
						<div class="clearer"></div>					
					</div>
					<div class="week">
						<a href="" class="day number">
							<span>Uke 13</span>
						</a>
						<a href="" class="day">
							<span>19</span>
						</a>
						<a href="" class="day">
							<span>20</span>
						</a>
						<a href="" class="day">
							<span>21</span>
						</a>
						<a href="" class="day">
							<span>22</span>
						</a>
						<a href="" class="day">
							<span>23</span>
						</a>
						<div class="clearer"></div>				
					</div>
					<div class="week">
						<a href="" class="day number">
							<span>Uke 14</span>
						</a>
						<a href="" class="day">
							<span>26</span>
						</a>
						<a href="" class="day">
							<span>27</span>
						</a>
						<a href="" class="day">
							<span>28</span>
						</a>
						<a href="" class="day">
							<span>29</span>
						</a>
						<a href="" class="day">
							<span>30</span>
						</a>
						<div class="clearer"></div>				
					</div>
					<div class="clearer"></div>
				</div>
			</div>

			#calendar {
			width : 432px;
			float : left;
		}

		#calendar h2 {
			text-align : center;
			float : left;
			margin-top : 26px;
			width : 294px;
		}

		#calendar-navigate-back, #calendar-navigate-forward {
			width : 64px;
			height : 64px;
			display : block;
			float : left;
			margin-right : 5px;
		}

		#calendar-navigate-back {
			background-image : url( 64/1leftarrow.png );
		}

		#calendar-navigate-forward { 
			background-image : url( 64/1rightarrow.png );
			float : right;
		}

		#month-calendar {
			clear : both;
		}

		#month-calendar div.week {
			width : 100%;
			height : 72px;
			float : left;
		}

		#month-calendar div.week a.day {
			color : #585858;
			width : 65px;
			height : 65px;
			background-color : white;
			border : 1px solid silver;
			display : block;
			float : left;
			margin : 5px;
			margin-bottom : 0px;
			margin-left : 0px;
			text-decoration : none;
		}

		#month-calendar div.week a.day:hover {
			border : 1px solid black;
		}

		#month-calendar div.week a.day.hidden {
			border : 1px solid transparent;
			background-color : transparent;
		}

		#month-calendar div.week a.day span {
			display : block;
			float : left;
			font-size : 25px;
			padding-top : 19px;
			padding-left : 18px;
		}

		#month-calendar div.week a.day.active {
			border : 1px solid black;
		}

		#month-calendar div.week a.day.active span {
			text-decoration : underline;
			font-size : 30px;
			padding-top : 15px;
			padding-left : 16px;
			color : black;
		}

		#month-calendar div.week a.day.off span {
			color : darkRed;
		}

		#month-calendar div.week a.day.number {
			background-color : #eeeeee;
		}

		#month-calendar div.week.active a.day.number {
			border-color : darkRed;
		}

		#month-calendar div.week.active a.day.number span {
			color : darkRed;
			text-decoration : underline;
			font-weight : bold;
		}

		#month-calendar div.week a.day.number span {
			font-size : 15px;
			text-align : center;
			display : block;
			width : 100%;
			padding-top : 24px;
			padding-left : 0px;				
		}

Endret av JohndoeMAKT
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste
×
×
  • Opprett ny...