rekken en strekken

Status
Niet open voor verdere reacties.

jeel2008

Gebruiker
Lid geworden
30 okt 2008
Berichten
839
hallo, hier
http://www.jeelsites.nl/rv.html
heb ik 3 layers.
eentje ligt boven (voor het menu later)
een ander ligt links (ook voor wat dingen)
en de 'hoofdlayer' ligt verankerd in de hoek rechtsonder. die rekt mee met de grote van de viewport, van je monitorscherm.
dat gaat goed zolang je scherm niet groter is dan het plaatje.

maar nu komen de problemen, nog afgezien vh feit of dat er mooi uitziet bij iemand die een groot , zeer breed scherm heeft (dan komt die boven en linkslayer misschien wel erg ver van de 'action' af te liggen, maar goed).

dat achtergrondplaatje is maar beperkt groot, dus dan krijg je 'paneelvorming' (zoals je in het voorbeeld ziet, mits je scherm groot genoeg is :) ), dat ie zich op een groot scherm weer laat zien. en nog eens en nog eens. en dat is lelijk en dat wil ik dus niet.
een optie zou zijn om een ENORM groot achtergrondplaatje te nemen, maar dat is ook zo ehmm...niet-subtiel.

als ik kon toveren dan zou ik dat plaatje ook mee laten rekken, dus eigenlijk groter dan het plaatje van oorsprong zelf is! dus niet alleen de div rekken en strekken maar het plaatje zelf. zodat er in beeld altijd maar 1 achtergrondafbeelding zichtbaar is en niet tig.
maar dat kan niet neem ik aan?
is hier een oplossing voor?
 
Laatst bewerkt:
Hoi jeel2008,
als ik kon toveren
... maar dat kan niet neem ik aan?
is hier een oplossing voor?
Kan wel: css kan toveren :D, is een oplossing voor. Zelfs twee.

De ene is met css3, maar de helft van de IE-surfers heeft geen IE9 en dus geen css3. Met javascript of een htc-bestand zou daar misschien iets aan te dokteren zijn.
De andere is met gewone css2.1. Die gaat als volgt:
  • Je maakt twee div's, precies even groot, en de één bovenop de ander.
  • In de onderste zet je de "background-afbeelding": als voorgrond-afbeelding in de html, met een opgegeven breedte van 100% = net zo breed als die div is. De hoogte niet opgeven, die volgt vanzelf naar rato. Het img schaalt nu mee met z'n container.
  • In de bovenoppe div zet je de content.

In de praktijk (daar omgekeerd, met alleen opgegeven 100% hoogte):

Verder kan je natuurlijk de ApDiv's grotendeels vergeten, en de (gecentreerde) pagina een max-width geven: dan loopt het niet de spuigaten uit bij XXL-brede beeldschermen.
  • Wat wel lastig kan worden, is veel tekst in de content. Dan moet je waarschijnlijk ofwel een interne scrollbar voor de content gaan invoeren (ben ik niet zo wow's van), ofwel de rest op een position:fixed zetten, ofwel de hoogte van de div's flexibel maken (met een hoog bg-img voor geval van meer). In de laatste optie zal je dan javascript nodig hebben om de onderop-div naar bevind van zaken steeds net zo groot te maken als de bovenste div met de flexibele content-hoogte).

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
hallo css hunter
bedankt voor je antwoord uiteraard
ik ga er later vandaag uitgebreid naar kijken, maar mn eerste vrees is, krijg je in het geval van geen Apdivs maar wel een max width vd pagina niet dit:
zie image

omdat de achtergrond-afbeelding stijf rechtsonder in de hoek moet blijven?
 

Bijlagen

  • monitor2.jpg
    monitor2.jpg
    92,4 KB · Weergaven: 61
hmmmmm...

hmmmm...
http://www.jeelsites.nl/rv2.html
probleem: de tekst gaat niet mee als het plaatje gaat schalen

dus zou ik tegen de bovenoppe div moeten zeggen: "luister, als het plaatje groter wordt omdat die meneer een heel groot scherm gaat, dan moet je natuurlijk wel meegaan"
dan zit ik te denken een een relatieve positioning, maar dat gaat niet, want de div ligt niet IN maar OP de andere div (z-index).

:confused:

ander probleem: ik moet al direct naar boven scrollen als ik de pagina open.... ?? terwijl het plaatje echt niet groter is dan mijn monitor. how come?
(zie scroll.jpg, dit is het eerste wat ik zie als ik m open, ik zit al onderaan de pagina bij opening)
 

Bijlagen

  • scroll.jpg
    scroll.jpg
    77,7 KB · Weergaven: 59
Laatst bewerkt:
Hoi Jeel,
Even het bovenstaande laten staan waar het staat, en geblinddoekt vanaf scratch begonnen. :p
Iets in deze geest?



Met vriendelijke groet,
CSShunter
 
Toch nog even de blinddoek afgedaan. ;)
In jouw testpagina heeft het img wel een breedte van 100%, maar de omliggende div heeft geen breedte (heeft dus als block-element max. 100% van de schermbreedte).
Betekent: als het scherm kleiner wordt dan de breedte van het img, dan is de div kleiner > dan wordt het img geschaald op 100% = de breedte van de div (= beeldvullend).
Maar als het een breed scherm is, dan heeft de div met z'n absolute positie geen automatische eigen breedte (blijft binnen het max. van 100% scherm), en dan is de 100% van het img altijd 100% van zichzelf > de div wordt dan niet breder, en het img blijft dusdoende hangen op zijn 1130px breedte.
Bij dit alles zijn er ook z'n consequenties voor de hoogte: als de breedte van het img bij een breed scherm gelijk blijft, blijft ook de hoogte altijd gelijk. De rek is er uit!
En omdat de img-div alleen een {bottom:0} + vaste hoogte van 600px heeft, vliegt het img bij grotere breedbeeld-schermen (met relatief weinig hoogte) acuut tegen het plafond. Iets dergelijks geldt ook voor de content: op bv. 1024*768px zit er bovenaan helemaal geen ruimte meer voor je header-strook; of de bovenkant van de content verdwijnt zelfs buiten beeld als je een paar toolbars in de browser hebt aanstaan.

Ergo: ook de hoogte van de img-div en de opper-div moet afhankelijk gemaakt worden van het beschikbare scherm.
En als ze alle twee dezelfde absolute positie hebben, maar relatief t.o.v. de linkerbovenhoek van de pagina (niet: van het scherm! Voorwaarde: de <body> moet een {position:relative} krijgen), plus hetzelfde formaat (via alle 4: top, bottom, links en rechts; resp. t.o.v. de bovenstrook en de zijkolom), dan blijft de pagina mooi gecentreerd, bij een ingestelde max. paginabreedte, en alles blijft flexibel op zijn plek. De opper-div dekt dan gewoon de img-div helemaal af: ze zijn volstrekt identiek.
En als de opper-div later in de html staat dan de onder-div met het img, hoeft er ook geen z-index aan te pas te komen. :)

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
hallo csshunter,

aha, ik geloof dat de franc valt.
ok, er viel niets meer te rekken. meer dan 100% kon niet.
dat deel heb ik. in de breedte snap ik het.

dan nu de hoogte:
en dan vanaf 'En omdat de img-div alleen een {bottom:0} + vaste hoogte van 600px heeft'.
ik zie m rekken naar links, dat wordt enorm. dus rekt ie ook enorm naar boven.
ok. maar dan zit ie met zn hoofd snel tegen het plafond. heb ik ook. so far, so good. ;)

maar hier dreig ik je kwijt te raken.
want de oplossing ervoor dat ie zn hoofd niet stoot is , of zou voor mij zijn, een topstrook maken, zoals je gedaan hebt. maar als ik het goed begrijp duwt die img-div die topstrook naar boven toe, helemaal uit beeld, omdat die image ruimte nodig heeft, zoals wij allemaal.

zit ik nu te raaskallen, of is dit hoe het ongeveer zit?

hoe dan ook, wederom zeer veel dank voor je antwoord uiteraard.
 
..., maar als ik het goed begrijp duwt die img-div die topstrook naar boven toe
Nop! De img-div (ik noem 'm de #contentbackground) duwt niets maar wordt geduwd!

Daarom mag ie zelf geen vastgeprikte hoogte (die van 600px of een andere waarde) krijgen,
maar definieer ik deze onderdiv als volgt:
  • Hij moet onderaan inderdaad op de rand van het scherm bivakkeren, dus {bottom: 0;}.
  • Hij moet bovenaan altijd onder de topstrook bungelen, die 200px hoog is, dus {top: 200px;}.
  • Nu zit z'n hoogte gevangen tussen de onderkant en 200px vanaf boven.
  • De linkerkant hadden we al: rechts van de linkerkolom van 200px breed, dus {left: 200px;}.
  • En de rechterkant valt samen met de rechterkant van de pagina-kolom (hoe breed die ook is), dus {right: 0;}.
  • Nu zijn alle 4 de buitengrenzen opgegeven (zonder opgegeven hoogte of breedte), en zit de div klemvast.
  • Dwz klemvast binnen de flexibele paginahoogte (=inwendige schermhoogte) en de flexibele paginabreedte (=windowbreed, dan wel max. 1500px).

Zie hier: ici.

De definitie van de opperdiv #content is in principe exact hetzelfde:
  • Ook absolute positie tov linkerbovenhoek van de pagina.
  • Ook {top: 200px; left: 200px; right: 0; bottom: 10px;}
  • Nou ja, in de praktijk niet 100% identiek: de bottom is 10px hoger gezet om geen doorgesneden regels precies op de onderrand van het scherm te krijgen (als er veel content is).
  • De #content staat dus op precies dezelfde plek (op die 10px na).

Zie hier: ici-2.


  • De groene doorlopende border van de #content valt nu samen met de rode streepjesborder van de #contentbackground, en van de rode streepjes is niets meer te zien (behalve onderaan).
  • Met de groene tekst van de #content gaat het idem dito: waar in het groen "content" staat, staat dat bovenop de rode "content" van het woord "contentbackground" dat erachter zit / staat / hangt / ligt.
  • Ga je nu trekken & duwen aan het browser-window: wat er ook gebeurt, opper en onder blijven altijd samenvallen.

Q.E.D. :)
Kan hiermee de jackpot vallen?
 
Laatst bewerkt:
hallo csshunter
de jackpot zou kunnen vallen, hoewel ik nog even alles in de praktijk moet nalopen.
zo direct heb ik één wedervraag: stel dat je nu heel veel content hebt, waar blijft dat dan al die tekst aan de rechterzijde?
rekt die tekst mee net zo breed als het scherm is van degene die de site bekijkt?
(je kunt nl wel een div eromheen leggen die mooi in het midden blijft en een vaste breedte heeft, maar dan komt de tekst, als je dat doet, zeer ver af te liggen van het menu bij mensen met een groot scherm?)
om een lang verhaal kort te maken, zie het image 'veelniks.jpg'. krijg je geen veelniks bij grote brede schermen en zo ja, is dat tegen te gaan?
of loop ik nu mn eigen staart achterna en komt het menu boven en links, de strook boven en links, mee naar het midden toe?
 

Bijlagen

  • veelniks.jpg
    veelniks.jpg
    100,9 KB · Weergaven: 58
Laatst bewerkt:
krijg je geen veelniks bij grote brede schermen?
Nee, want de pagina-breedte is gemaximaliseerd.
Dan wordt het niet dit:

rek-breed.png

Dwz. met zowel veel niks als veel regellengte.
Maar dit:

rek-smal.png

Dus net zo veel niks als met een minder breed scherm:

rek-klein.png

of loop ik nu mn eigen staart achterna en komt het menu boven en links, de strook boven en links, mee naar het midden toe?
Ja. :)
 
Laatst bewerkt:
hallo csshunter,

ok!
met de tekstbreedte kan ik nog wat spelen, alsook met de achtergrondkleur.
afijn, uiteraard weer bedankt voor de tutorial en wellicht tot wederhoren.
 
pwaaa pwaaa
t loopt hier een beetje spaak

http://www.jeelsites.nl/test.html

heb allerlei dingen geprobeerd kreeg het niet voor elkaar een plaatje op de goede plek te tonen
(het tonen ging nog wel, maar niet op de goed plek)
ooit hebben we het hier al eens over gehad.
maar toen had ik geen last van andere divs die nu de content bijvoorbeeld vormen.

kan ik niet gewoon een div in de content div leggen en dan een soort van anker-id maken:
#toonhierhetplaatje
met een linkermarge van 150px of zo?
 
miep-miep!

kan ik niet gewoon ...

Proberen is weten! :P

... of nog veel gewoner: het img een id geven.

PS: Doe je nog even wat de css-validator zegt? "Familienamen die spaties bevatten moeten tussen aanhalingstekens worden geplaatst."
PS2: Herstel! Ik zie floeps de #content een absolutie positie krijgen :) > daarmee wordt alles anders, maar niet voor wat er in zit.
PS3: Het bg-img zit er nu in als bg-img > dus er wordt niet veel gerekt of gestrekt (helemaal niet, zelfs).
 
hakken en zagen

hallo csshunter
PS2: Herstel! Ik zie floeps de #content een absolutie positie krijgen > daarmee wordt alles anders, maar niet voor wat er in zit.
PS3: Het bg-img zit er nu in als bg-img > dus er wordt niet veel gerekt of gestrekt (helemaal niet, zelfs).

dat de zaken niet meer in orde waren, kwam waarschijnlijk door al het hakken en zagen.
door dat geknutsel heb ik de aandacht denk ik te veel op andere dingen gelegd, het proberen te tonen van de plaatjes.

Proberen is weten!
je hebt helemaal gelijk, en dat had ik dus ook al gedaan.
maar floeps, de content vloog helemaal naar rechts.

morgen een nieuwe poging, toch bedankt
 
strektest

rek-en strekoefeningen deel3

het goede nieuws:

alles toont, plaatjes en content
http://www.jeelsites.nl/strektest/takkenlevenstrektest.html

het mindere nieuws: pc-ogen -->:shocked:

en verder
die lange contentflap die steekt er wel erg ver uit, zie andere pagina
maar ja, daar doe je verder niet zo veel aan heb ik het idee

ik weet het niet...voldoet dit nu of heb ik ergens zitten pitten?
 
enkele uren later...
zie nu op een andere pc dit...zie image
hmmm, dacht toch echt dat ie netjes rechtsonder in de hoek zou liggen
niet dus
 

Bijlagen

  • breed.jpg
    breed.jpg
    99 KB · Weergaven: 52
Op de plaats: rust?

Hoi Jeel,
pc-ogen --> :shocked:
Aha, tijd geworden om even te temperaturen. > Ja, beetje stress-verhoging zie ik.
Dan schrijf ik u het volgende pilloze recept voor *):


  1. Wat afstand nemen: minstens 1m vanaf het beeldscherm.
  2. Niet naar de code kijken, maar voor jezelf vaststellen: wat wil ik nu precies dat er gaat gebeuren?
  3. Het voorgaande kan ook prima tijdens een ontspannen fietstochtje. :)
  4. Als de ideeën zijn ingedaald, schetsje op A4 maken met old-fashion potlood & gummetje.
  5. Met schone lei beginnen **), en alleen die dingen uit eerdere versies er in zetten die goed gingen: de rest is ballast of takkenzooi! ;)

takken.png

Gewetensvragen bv.:
  • Moet het omstreepte content-gedeelte bij veel content scrollen onder de roze bovenbalk door? Of moet de roze balk mee omhoog scrollen?
  • Moet de groene zijkolom tegelijkertijd met de content mee omhoogscrollen als er veel aapjes zijn, of moet de zijkolom dan een onafhankelijke scrollbar krijgen?
  • Hoort het linksboven-vierkantje bij de zijkolom of bij de bovenstrook?
  • Moet de takken-afbeelding paginavullend zijn op vaste positie, of alleen voor het content-gedeelte de achtergrond vormen?
  • In geval van het laatste: moet de achtergrond mee-omhoog scrollen met de content, of vast blijven staan?
  • Van dat soort dingen!

Vaak is de oplossing nabij als de vraag goed geformuleerd is! :) ***)

De smalle en hoge tekstkolom
Ik had er maar als wild-west-idee een 45% padding aan de rechterkant in gezet, om nog iets van de background-figuur te kunnen zien. Dan kan natuurlijk ook minder worden, al dan niet met een semi-transparantie voor het tekstgebied.

Even kijken naar je laatste screenshot...
Juistem, het klopt ("natuurlijk") wat er gebeurt: de #contentbackground-div heeft geen referentiepunt (een {position:relative} hogerop in de waterval, en het bg-img staat weliswaar in een {top:0;left:0;right:0;bottom:0;} box, maar automatisch in de linkerbovenhoek daarvan.
  • Altijd rechtsonder: html {position: relative;} en #contentbackground {background-position: 100% 100%;} zou het moeten doen.
Maar in dat geval is er geen max. paginabreedte bij heel brede schermen: want (a) de body staat vrolijk op 100% breed ingesteld, en (b) als de body een max-width zou krijgen, moet de {position:relative;} niet aan de <html> maar aan de <body> geknoopt worden. - Tenzij de inhoud-breedte wel een max. moet krijgen, maar de takken-bg altijd schermvullend moet zijn.

Zo, ik hoop dat dit de verwarring doet afnemen. ;)

Met vriendelijke groet,
CSShunter
_________
*) Dokter heeft dit op zichzelf uitgeprobeerd als proefpersoon, en is in elk geval niet zieker geworden. Eventueel het recept de volgende dag of na de siësta herhalen. Onprettige bijverschijnselen: geen. Na genezing is deadline makkelijker gehaald.

**) Niet tegelijkertijd een extern stylesheet (of zelfs: 2x dezelfde...) + ook nog <head>-styleblok gebruiken, dan raak je al gauw het overzicht kwijt; maar in de probeerfase alles in de <head> zetten; zie Golden Rule 4.

***) Ik weet niet helemaal wat de bedoeling is, en kan dus nog niet zoveel zeggen. Moet het vooral een plaatjesgaanderij worden met op-poppende image-vergrotingen? Of al dan niet op-poppende tekst-gedeeltes, of een combi, of anders?
 
medicijn

beste cssdokter
ik ga vandaag uw medicijn proberen.
wel kan ik al zeggen:
Moet het vooral een plaatjesgaanderij worden met op-poppende image-vergrotingen? Of al dan niet op-poppende tekst-gedeeltes, of een combi, of anders?
er zal weinig tekst zijn, en ook niet eens veel plaatjes.
dus ik vermoed een minimum aan scrollactiviteiten.

Moet het omstreepte content-gedeelte bij veel content scrollen onder de roze bovenbalk door? Of moet de roze balk mee omhoog scrollen?
ja, liefst wel. dat was het probleem. de achtergrond heeft eigenlijk van zichzelf al zijbalken, dus die had ik niet nodig. de tak die uitsteekt, boven, wil ik tegen de bovenrand hebben.
de menus links en rechts moeten er dus overheen komen te liggen. zie * even verder. en dan was weer het probleem: zijn ze deel van het geheel of hebben ze een toko op zich? ik wilde dat ze deel van het geheel werden en dus meekropen als er iets verkleind of vergroot zou worden, maar daar kom ik ook niet helemaal uit.

Moet de groene zijkolom tegelijkertijd met de content mee omhoogscrollen als er veel aapjes zijn, of moet de zijkolom dan een onafhankelijke scrollbar krijgen?
geen onafhankelijke scrollbar

Hoort het linksboven-vierkantje bij de zijkolom of bij de bovenstrook?
goeie vraag. maakt op zich niet uit als die divs kunnen overlappen.
* dat was ook iets waar ik mee zat. kunnen divs gewoon elkaar overlappen?
via een z-index toch? maar iets in me zegt dat jij daar op 1 of andere manier niet zo enthousiast over was, of vergis ik me hier?

Moet de takken-afbeelding paginavullend zijn op vaste positie, of alleen voor het content-gedeelte de achtergrond vormen?
In geval van het laatste: moet de achtergrond mee-omhoog scrollen met de content, of vast blijven staan?
Van dat soort dingen!
takkenafbeelding moet vanaf linksonder zich uitvullen naar boven en altijd paginavullend zijn. vast of mee met de content? hmmm...ik zou zeggen vast. als ie maar rekt voor kleine en grote schermen.


wij rekken en strekken vrolijk verder, maar uiteraard wederom bedankt.
jeel2008
 
Laatst bewerkt:
gymnastiek

Ha, tipjes van de sluier opgelicht.
Ik doe af en toe ook wat rek- en strek-oefeningen.

Om bij het begin te beginnen: de achtergrond-rekking.
Het img heb ik 1200*500px gemaakt, zodat je goed kunt zien of/hoe het schalen werkt.

=======

Test: rekken-en-strekken-ici-3.htm


  • Gedaan: #contentbackground (rode streeplijntjes) met img van 100% width en 100% height er in. Ook het woord "contentbackground" in die box gezet: zou onzichtbaar moeten blijven omdat het img de hele box opvult.
  • Resultaat 1: IE7 geeft veel te hoge hoogte, die bij window-slepen terugschiet in de echte hoogte van het img (met daaronder het woord "contentbackground"). :shocked:
  • Resultaat 2: Andere browsers en IE8 en hoger doen het wel goed: figuur rekt en trekt altijd helemaal mee met schermbreedte en schermhoogte.
  • Resultaat 3: Daarmee blijft de figuur dus niet in proportie !
  • Vraag: Is dat de bedoeling?
  • Resultaat 4: Er kan dus niet alvast een bovenbalk of zijbalk in de figuur gemonteerd worden: want de breedte van zo'n zijbalk-gedeelte en/of de hoogte van het bovenbalk-gedeelte gaat meeschalen (maar dus ook weer niet gelijk op: is afhankelijk van de scherm-verhouding).
Maar als IE7 niet wil rekken of strekken, dan moet IE7 buigen! ;)

=======

Test: rekken-en-strekken-ici-4.htm


  • Gedaan: uitgevonden dat het schalen in IE7 wel goed gaat bij toepassing van een MS-only AlphaImageLoader voor de box.
  • Resultaat: IE's geven nu een dubbele figuur: de goede als background-img (!) van de box, maar de verkeerde eroverheen als html-inhoud <img src="..." /> van de box.
  • Ook gedaan: html-img voor IE verborgen door een Inverse Conditional Comment (= wordt alleen voor niet-IE's uitgevoerd).
  • Resultaat: Alle browsers gelijkgetrokken.
  • Resultaat: Breedbeelders krijgen enorm horizontaal uitgerekte figuur te zien.
  • Vraag: Is dat de bedoeling?
  • Vraag: Zo ja, moet de inhoud wel gemaximaliseerd worden (> dan komt de linker-"zijbalk" niet op de beeldschermrand, maar een stuk naar het midden in de figuur.)
Dus gaan we even een max. bekijken.

=======

Test: rekken-en-strekken-ici-5.htm


  • Gedaan: Breedte van de (gecentreerde) <body> gemaximaliseerd met {max-width:1000px;} = simulatie als je op 1280*1024 kijkt van wat er op een breedscherm gebeurt als je aan het maximaliseren slaat.
  • Resultaat: Doet het in alle browsers, breedte kan niet overdadig worden.
  • Resultaat: L/R naast de figuur komt de bg-color van de html doorpiepen (eventueel kan daar een vervolg-img in gezet worden, maar dat schaalt dan niet mee!).

=======
Hamvraag voor 't moment dus: wil je op 4 of 5 gaan voortborduren?

Gymschoenen weer uit! :)
CSShunter
 
Laatst bewerkt:
hallo csshunter, ik wilde je net gaan schrijven.
dat doe ik eerst, daarna kijk ik naar je antwoord.
hier http://viewlike.us/?url=www.jeelsites.nl/strektest/testdw.html&button.x=60&button.y=16
kun je zien hoe dit eruit ziet: http://www.jeelsites.nl/strektest/testdw.html
met behulp van dreamweaver voorgebakken paginas
en wat hakken en zagen
en rekken en strekken
tot ik een ons weeg

het vreemd is hier (http://viewlike.us/?url=www.jeelsites.nl/strektest/testdw.html&button.x=60&button.y=16)
dat ie niet eens in het midden toont!
terwijl ik toch een margin: 0 auto; gaf

nu breekt mn klomp ook nog

wij knutselen vrolijk, doch in onbegrip, verder

ps: ja, de figuur moet wel in proportie blijven, als het kan
ps2:
Breedbeelders krijgen enorm horizontaal uitgerekte figuur te zien
. nee, is niet de bedoeling
ps3:
Vraag: Zo ja, moet de inhoud wel gemaximaliseerd worden (> dan komt de linker-"zijbalk" niet op de beeldschermrand, maar een stuk naar het midden in de figuur.)
nee, die mag naar het midden komen. zo eenzaam voor de inhoud als het menu op grote schermen helemaal links blijft hangen
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan