Kaders rond hotspots in safari en Ei

Status
Niet open voor verdere reacties.
Ja, klopt helemaal:
Code: 
a#hme { margin: 0 0 0 0; 
                  width: 320px; }
/*                       =====    */
a#slp { margin: 63px 0 0 320px; 
                  width: 113px; }
/*                       =====    */
a#eet { margin: 63px 0 0 433px;	
                  width:  89px; }
/*                       =====    */
a#fst { margin: 63px 0 0 522px;	
                  width: 122px; }
/*                       =====    */
a#mtr { margin: 63px 0 0 644px;	
                  width: 111px; }
enz.
(ik had de a#slp op 114px breed gezet, die werd dus 1px overlapt door de volgende; maakt niet echt uit, maar hier gecorrigeerd)

Wat is dan die 0 0 tussen 63px en 644px?
Klik om te vergroten...
Dat is de margin-right en de margin-bottom van de links.

Een margin heeft 4 mogelijkheden, en in de notitie moeten die altijd alle 4 vermeld worden *), plus achter elkaar staan in de volgorde:
Code: 
.. { margin: [I]top right bottom left[/I]; } /* bovenaan beginnen, en met de klok mee, zegt het ezelsbruggetje */

Ook andere eigenschappen die 4 variabelen hebben, werken zo, bv. de border-breedte ook:
Code: 
.. {border-width: 1px 1px 2px 2px; }
=  {border-width: [I]top right bottom left[/I]; }

  • Er is ook een verkorte notitie, bv. als Top/Bottom en Left/Right dezelfde waarden hebben; die wordt o.a. toegepast bij een:
    Code: 
    .. {margin: 0 auto; } /* Top/Bottom: 0, Left/Right: automatisch (= bij opgegeven breedte: gecentreerd) */
  • Zie bv.: w3schools.com/cssref/pr_margin.asp (uitgebreid css-tutorial, ook erg handig als naslagwerk!)

Maar de background-position heeft maar 2 variabelen, alleen de x en de y voor het startpunt:
Code: 
.. {background-position: [I]x y[/I]; }

Met vriendelijke groet,
CSShunter
___________________________________________
*) Of je moet ze apart benoemen, bv.:
Code: 
a#slp {
    margin-top:  63px;
    margin-left: 320px;
    width: 113px; }
a#eet {
    margin-top:  63px;
    margin-left: 433px;
    width: 89px; }
enz.
En het had hier ook op een andere manier gekund: de margin-top van alle links tegelijk op 63px zetten (met weer een uitzondering voor de #hme), en dan alleen de margin-left voor de aparte links opgeven:
Code: 
#menu a {
    ...
    margin-top: 63px;
    }
a#hme { margin-top: 0; width: 320px; height: 140px; }
a#slp { margin-left: 320px; width: 114px; }
a#eet { margin-left: 433px; width:  89px; }
a#fst { margin-left: 522px; width: 122px; }
enz.
Zo zijn er in CSS vaak verschillende manieren om hetzelfde te doen. Je kunt kiezen wat je zelf het handigste vindt. :)
 
Laatst bewerkt:
aaaaahh tuurlijk. ja snap t helemaal.
Dan ga ik maar eens proberen om de racingteam versie met css te maken. :shocked:
Maar het moet wel lukken. Vallen en opstaan denk ik haha

Nogmaals heeeeel erg bedankt voor je les in css. Mijn vraag is el erg uitgebreid beantwoord hihi
Ben er helemaal gelukkig mee.
:thumb:
xxx
 
Okidoki, veel succes!

Zit nog een nagekomen voetnootje in m'n vorige, want ik was natuurlijk weer niet snel genoeg.
Maar ik leer het wel: maar 1 minuut verschil. ;)

Groetjes,
CSShunter
 
Laatst bewerkt:
ja hey, ben je nu nog zo sloom hahaha :P
geeft niet hoor, vind het al knap als ik 1 manier onthoud haha

Thanks:thumb:
 
O ja, de racingteam css staat al klaar in de idhof.css:
Code: 
#racingteam {
	width: 170px;
	height: 110px;
	display: inline-block;
	background: url(../images/idhof-racingteam-sprite.png);
	}
#racingteam:hover, #racingteam:focus { background-position: 0 -110px }
En de sprite is er ook al: idhof-racingteam-sprite.png
En de html is er ook al in de van-hotspots-naar-css.htm

Dus als je haast hebt ... ;)
Maar helemaal zelf uitvinden is natuurlijk veel leuker! :thumb:
 
nee ik bedoelde het site gedeelte van racingteam, is net iets anders qua vormgeving, andere navigatie balk enz. maar wel dezelfde opbouw als het goed is.
moet dan toch even zelf gaan kijken (lees puzzelen) hoe het gaat met patrijspoorten enz haha
 
Ah, I see, de subsite: "dat gaat op precies dezelfde manier". :P

Maak er wat moois van! :thumb:
 
yep. als het goed is moet het nu wel lukken haha
anders trek ik bij je aan de bel =)

:D
 
woohoo het is gelukt. met wat gedoe. Was vergeten de css op de juiste plaats op te slaan dus hij vond mij afbeeldingen niet. Maar eer ik daar achter was.......
Heb alleen nog een aanpassing die bij mij maar niet wil werken.
Ik heb de rechterkolom in 2 stukken verdeeld. Nu willen we dat de foto's klikbaar zijn en dat daar de lightbox komt. Dus dat icoontje komt te vervallen. Ik heb van alles geprobeerd, maar zodra ik de code van de lightbox plaats verspringen de andere velden. (footer enz)
Hopelijk heb je nog een tip voor me :o
http://indenhof.nl/test/index-test.htm
 
oja, ik heb dat straks ook met de fotopagina van de subsite over het racingteam. Ik heb die foto's nu in een tabel staan, maar jij hebt daar vast een betere oplossing voor.
Hier heb ik gelukkig wel de mogelijkheid om de plugin van DW te gebruiken voor de lightbox, omdat ik alle foto's op die pagina moet zetten ipv 1 foto, waar alle andere foto's achter hangen
 
Hoi NeoMuis,
Als een webpagina plots niet doet wat je wilt, ...
Klik om te vergroten...
zie m'n handtekening!

Dus eerst maar de 18 html-errors er uit gehaald, o.a. de dubbele ID's in de rechterkolom, en de afstand tussen beide plaatjes geregeld met css.



De css-validator vond het al 100%.
Dus nu de lightbox er in. De links naar de lightbox-scripts niet in de <head> gezet, maar vlak voor de </body>, dat geeft een snellere pafina (de link naar het lightbox.css komt wel in de <head>).
En inderdaad: de "overlay" (transparante grijze tussenlaag) van de lightbox zit niet op de goede plaats.

Ziehier de ziekteverschijnselen: idhof-nw-test-lbox-ongecorrigeerd.htm.


  • Oorzaak: de #lightbox heeft een absolute positie in het lightbox-systeem, en zit binnen de <body>, die de paginabreedte heeft en niet de schermbreedte.
  • Maar de <body> heeft een {position: relative} (is nodig voor goede vertoning in IE7). Dan gaat de #lightbox de absolute positie regelen ten opzichte van de body: en komt dus aan de linkerkant niet voorbij waar de paginabreedte ophoudt. Daar zit dus een kolom die niet meedoet met het grijs.
  • Maar de #lightbox heeft wel een breedte van 100% (van de schermbreedte), dus wat er aan de linkerkant te weinig is, komt er aan de rechterkant bij. D.w.z. er komt een scrollbar L/R onderaan, en rechts overbodige grijze ruimte.
    [*}Internet Explorer 7 doet het anders (het zal weer eens niet): die pakt 100% van de paginabreedte, en komt dus ook rechts niet voorbij de paginagrens.
Wat nu?
Gelukkig is er een simpele oplossing:
  • De <body> mag geen {position: relative} krijgen. Met enige mazzel blijkt IE7 ook goed te reageren op een {position: static}, wat eigenlijk helemaal niet nodig zou moeten zijn. *)
  • De speling aan de bovenkant van de overlay was de 20px ruimte die de header bovenaan heeft, en is door de static positie ook verdwenen (de absolute positie van de overlay begint nu verticaal gewoon op 0).
  • En IE7 kan geforceerd worden tot de goede breedte door niet het lightbox-javascript de breedte van de overlay te laten bepalen, maar de breedte van 100% keihard vast te spijkeren in een voorrangsregel in de css.

Al met al wordt het in de css:
Code: 
body {
	position: static; /* voor IE7 */
	}
#overlay {
	width: 100% !important; /* voor IE7 */
	}
Gered! Voor de veiligheid kunnen de links naar de vervolg-foto's nog in een <div id="lbox"> gezet worden die een {display: none} krijgt; maar het zijn toch lege links, en eigenlijk is het niet nodig.



Met vriendelijke groet,
CSShunter
__________
*) De {position: static} is de "initial value" (standaard-waarde) van de position-eigenschap; zie de position-eigenschappen in de css-specificatie. Je ziet 'm in stylesheets dan ook meestal niet gebruikt worden. De {position: static} kan b.v. van pas komen als met javascript een absolute positie teruggezet moet worden naar normaal.

PS:
O ja, er staat nu: "Camping-café indenHof (voorheen camping café indenHof) ... enz." > Wat is het verschil, behalve het koppelstreepje? ;)
 
Laatst bewerkt:
Goedemorgen Hunter,
Bedankt ik ga t proberen. Snap alleen die fouten niet goed. Hij zegt dan dat er < of> mist maar die staan er toch. Of begrijp ik het verkeerd?

Maar ik zie dat die lightbox dan ook wat meer haken en ogen heeft als dat ik dacht.

Camping-café indenHof is hoe de klant het graag wil. Ik denk dat hij daarmee Camping en café wil laten zien, zeg maar. kan het weer heel goed uitleggen:shocked: Het is nog een beetje vroeg en al vrijdag haha.
Maar ik weet het ook niet heel precies hoor, waarom hij het zo wil.

Ik ga in ieder geval ff kijken of het gaat lukken met je tips en advies.

xxx
 
Hoi NeoMuis,
Ja, het is soms wat lastig om er achter te komen wat de html-validator bedoelt.
Als er dit staat ...:

omittag-no.png

... dan betekent dat:
  • de eind-tag voor deze "meta" is weggelaten, maar in de specificatie staat "OMITTAG : NO", de eind-tag mag niet weggelaten worden.
Dat is wat verwarrend, want een "meta" heeft geen eigen </meta> eind-tag.

Maar in het toelichtende zinnetje onderaan staat het beter:


  • You may have neglected to close an element,
    = u kunt vergeten zijn een element te sluiten. Bijvoorbeeld een <p>.... zonder </p>.

  • or perhaps you meant to "self-close" an element, that is, ending it with "/>" instead of ">".
    = of misschien bedoelde u een "zelfsluitend" element, dat is met " />" op het eind in p-laats van " >".

Het laatste is hier het geval. Een meta heeft geen eigen eind-tag, en is dan ook een "leeg element": er kan niets aan html-code tussen de begin-tag en de eind-tag staan.
  • Zo zijn er een paar meer. Bijv. een <img>-tag is ook een leeg element. In de eigenschappen binnen de tag <...> staat wel waar het img opgehaald moet worden e.d., maar dat telt niet.

En in xhtml moet een leeg element zichzelf afsluiten door een slash / vlak voor het laatste vishaakje >.
Het moet hier dus zijn (hèhè):
HTML: 
...
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
...
<img src="..." width="..." height="..." alt="" />
...
<br />
...
  • Dit is anders dan bij een Doctype html4.01: daar mag de / er juist niet bij (want html4 kent het /> verschijnsel niet).

De rode met stippeltjes onderstreepte haakjes < en > in de foutmeldingen betekenen dat ongeveer daar de fout zit; het letterteken waar het onder staat hoeft zelf niet persé fout te zijn.

Met vriendelijke groet,
CSShunter
__________
PS
De naam: ik begrijp het al "Gasterij indenHof" is de nieuwe naam, en "Camping-café indenHof" was de oude naam. Zo staat het ook op de actuele homepage indenhof.nl.
Maar op de testpagina staat drie keer "Camping-café indenHof", dat moet nog even aangepast worden.
 
Laatst bewerkt:
aaah oke. Dat is dan ook een gedoe...Hoe zit dat straks dan met HTML5?

Ja overal inderdaad Gasterij, Ik moet bij de testpagina inderdaad de tekst nog aanpassen =) Ook de images nog kopje kleiner maken en foto pimpen haha. Maar ik wilde eerst even zien dat alles goed werkte, dan kon ik daarna nog puntjes op de i zetten.
Bedankt voor het meedenken in elk geval =)

xxx
 
NeoMuis zei:
aaah oke. Dat is dan ook een gedoe...Hoe zit dat straks dan met HTML5?
Klik om te vergroten...
HTML5 is een stuk vergevingsgezinder dan z'n voorgangers. Je mag dan ook zelf weten of je <img > elementen e.d. afsluit of niet. Je kunt een valide xhtml pagina dan ook zonder veel problemen omzetten naar html5, gewoon door het doctype aan te passen.
 
Ja, meestal gaat dat zonder meer goed.

Het kan wel wat lastiger worden als je geïmporteerde snufjes op je pagina hebt staan, die zich niet aan de html5-reglementen houden.
Voorbeeld:
  • De xhtml-strict pagina idhof-nw-test-lbox.htm is volgens de html-validator 100% valid html.
  • Je vervangt het doctype door html5: idhof-test-html5.htm.
  • De pagina blijft dan in alle browsers prima werken, en de html-Tidy validator in Firefox vindt het goede html.
  • Maar de html-validator signaleert opeens 13 fouten. :rolleyes:

  • Die zitten allemaal in de niet toegestane waarde van het "rel" attribuut, dat er door lightbox2 is in gezet.
    Alle andere html blijft gewoon correct. :)

In dit soort gevallen moet je dan een workaround zien uit te vinden, die de ongeldige (maar wel nodige!) code aan het zicht van de html-validator onttrekt.
Hier kan dit vrij eenvoudig door steeds de rel="lightbox[indenhof]" uit de html weg te halen, en deze er dan via een toegevoegd javascriptje weer in te zetten:
HTML: 
<script type="text/javascript">
// <![CDATA[
	var lboxStart=document.getElementById('lboxStart');
	lboxStart.setAttribute('rel','lightbox[indenhof]');
	
	var lboxA=document.getElementById('lbox').getElementsByTagName('a');
	for (var i=0; i<lboxA.length; i++){
		lboxA[i].setAttribute('rel','lightbox[indenhof]');
	}
// ]]>
</script>

Maar hiervoor moet je wel precies weten hoe zo'n geïmporteerd script werkt, en hoe je dat kunt aanpassen om het valid html te maken.
Het zou veel makkelijker zijn, als alle scripts, add-on's, gadgets, widgets e.a. mooie snufjes uit zichzelf al valid waren!
Dat zouden de snufjes-ontwerpers ook moeten kunnen bedenken! ;)

Met vriendelijke groet,
CSShunter
____________
*) Gelukkig heeft de lightbox er geen invalid css bij gemaakt. Dat kan je ook nog overkomen bij import-moois ...
 
Laatst bewerkt:
jeetje, ja ik verdiep me dus duidelijk te weinig in webdingetjes en -datjes. Maar ja je kunt niet alles weten he. ;)
 
Yep, gezien! :thumb: Gefeliciteerd!

En nog even de goede naam?
Er staat nu:
Welkom bij Camping-café 'indenHof'
Gasterij indenHof (voorheen camping-café indenHof) in ...​


Waarschijnlijk is de bedoeling:
Welkom bij Gasterij 'indenHof'
Gasterij indenHof (voorheen Camping-café indenHof) in ...​


Groetjes,
CSShunter
______
PS: als je deze neemt: idhof-fotos-home.jpg, ben je 175-30= 145kB goedkoper/sneller uit dan met de png-met-transparantie. ;)
(de achtergrond is hier toch wit, en transparantie is niet nodig; de transparantie van een png vraagt nl. een extra kB's etend "alpha-kanaal" waarin de transparantie-eigenschappen moeten worden opgeslagen).
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan