www.css-voorbeelden.nl

Ha, die smiley kreeg ik ook. Dit forum vertaalt die smileys naar vreemde teken-volgordes, zoals twee keer ; achter elkaar. Hebben trouwens veel forums. Type je 'n stukje code, krijg je opeens smileys.

Of die nieuwe versie erop zetten zinvol is, kan ik niet beoordelen. Als hij enigszins werkt in de meest gebruikte browsers (Google Chrome, IE 8/9, Firefox, Safari) zou dat kunnen. Maar persoonlijk wacht ik vaak liever tot iets min of meer af is, want als je later de code gaat veranderen en dat gaat écht mis, zit je met 'n probleem in je live site. (Dit was een bericht van de bij mij zeer actief aanwezige Afdeling Schade en Schande.)

Waar het mij vooral om gaat: als ik morgen iets downloadt, moet het hetzelfde zijn als waar jij aan werkt. Of in ieder geval vrijwel hetzelfde. Zodat jij, aangenomen dat het lukt, de wijzigingen ook aan kunt brengen.
Als ik het heb gedownload en bij mij erop heb gezet, kan ik echt kijken of het overal werkt. En dan kan ik hier de wijzigingen neerzetten, maar als dat nog niet lukt, kun je ook bij mij op de server kijken. Maar dat werkt alleen als we het over ongeveer dezelfde code hebben.

Ik heb dat verplaatsen vanaf m o v i enz. gedaan, en daar werkte het. Dus daar moet ik dan toch even grondig naar kijken.

Ja, in code-teksten zijn die smileys gevaarlijke stuff.

Ik werk nu dus in een andere versie. Maar het zijn geen grote veranderingen.
Dat wat ik dan evt. zou uploaden is maar een klein gedeelte van de site. 5 paginas.
Het is het movimag_portaal, de C&A en Flatscreen subportalen, een link naar de Englestalige versie van het portaal en een submenu site waar ik de lengte van de tekst tussen 2 foto's heb uitgeprobeerd. De linken tussen deze 1e vier pag. werken.

Maar die 1e drie zijn het belangrijkste: de basis voor de rest. En dat is "copy en past" werk.
Voor mij maakt het niet uit. Ik dacht dat het misschien overzichtelijker voor jou zou zijn.

Mij maakt het ook niets uit. Tja, nou wordt het moeilijk 'n beslissing te nemen
In principe kijk ik alleen maar naar die afbeeldingen en die video. Dat is maar 'n klein stukje van de html/css, en dat kan ik er met Firebug en zo makkelijk uitfilteren. Jouw code is heel overzichtelijk met netjes inspringen en zo (dat zie je wel 'ns anders...), dus die commentaren, daar heb ik geen last van.
Wat eigenlijk alleen belangrijk is: als ik nou met een briljant stuk css kom (ahum), dan moet jij het nog kunnen verwerken. En als de site in jouw computer totaal anders is als die op de server, dan kan dat lastig worden.
In het verleden, toen ik nog op allerlei forums actief was met vragen en zo, kwam dat met enige regelmaat voor. Vandaar.

Overigens denk ik ook wel dat je het vrij makkelijk moet kunnen verwerken, want ik denk eigenlijk niet dat het om heel grote veranderingen gaat.
Dan ga ik er morgen mee spelen.

Laten we het dan maar op de oude versie houden, stel dat er iets met uploaden misgaat .
Ik neem aan dat ik het wel in de nieuwe versie kan implanteren, het gaat tenslotte "alleen" om de werking van het effect.
In de nieuwe versie zijn wel wat aanpassingen van de positie van de foto's in de kolommen en in de content.
De 3 kolom foto's heb ik bvb iets verder uit elkaar gezet, dat gaf wat meer visuele ruimte.
En ik heb ten koste van de content de kolommen iets breder gemaakt. Dat soort dingen.

Ik kan je natuurlijk ook de map mailen waarin de nieuwe versie staat.

Ik doe het wel gewoon met de oude versie. Ik denk ook dat het eigenlijk vrij simpel is. En mocht het toch niet lukken in de nieuwe, dan kunnen we daar altijd ook nog even naar kijken.

Ik kreeg net dit berichtje binnen

You can use Firefox or any other browser for external preview (F8) in
HTML-Kit 292. For internal preview though, HTML-Kit 292 uses IE. Firefox
didn't have a good way to integrate with internal preview at the time of
development (still doesn't).

HTML-Kit Tools supports IE and Chrome/WebKit for internal preview, and
all browsers as well as smartphones/tablets for external preview.
Chami

Tja..., jammer.

Ik heb even gekeken bij html-kit, en ik denk dat ik het begrijp.
De nieuwste versies van html-kit herkennen ook veel html5, maar inderdaad via IE.
Ik neem aan dat jij nog met XP werkt. In dat geval heb je IE 8. De rendering machine van Microsoft is niet los te gebruiken, zoals webkit of gecko (beide open source). Dus html-kit zal in dat geval vastzitten aan IE 8. En die kent helemaal niets van html5. Ook geen video.
Tegen de regels in (tja, Microsoft...) negeert IE 8 en eerder (IE 9 doet het eindelijk goed) onbekende elementen. Hij zou <video> als een onbekend element moeten behandelen, en dan zou je er toch css aan moeten kunnen geven. Helaas...
Je kunt dat weer oplossen door wat JavaScript te gebruiken, maar dan ga je JavaScript gebruiken om de preview van html-kit te corrigeren, in de hoop dat dat gaat werken in Firefox, Safari, enz. Eh, je vroeg 'n paar posts geleden of je gek aan het worden was. Nou, als je dit gaat doen wel, denk ik.

Maar dit zou dus verklaren waarom je het in Firefox wel ziet en in html-kit niet.
Heb je dit trouwens ooit gelezen:
http://www.chami.com/html-kit/faq/pages ... eview.html
Dat zou het mogelijk maken met html-kit Firefox te openen voor de preview, als ik het goed begrijp.
Overigens is het feit dat IE 8 <video> niet kent geen probleem, want binnen <video> wordt speciaal voor dit, dit, dit, dit haalt-die-adem kwaliteitsporduct een aparte tag met flash neergezet.

Ik geloof niet dat ik dat gelezen heb, maar uiteindelijk heb ik firefox wel als external browser kunnen laden. En die kun je dan inschakelen met de F8.
Maar dat werkt niet lekker.

Maar het rare is, hoe heb ik het dan de vorige keer gedaan?
Alhoewel er toen ook veel problemen waren.
En zeker toen ik met dat <video> element aan het spelen was.
Nu begrijp ik het.

Eerder zei ik tegen je dat ik het gevoel had dat ik iets miste.
En wat dat was is nu duidelijk geworden.

Overigens is het feit dat IE 8 <video> niet kent geen probleem, want binnen <video> wordt speciaal voor dit, dit, dit, dit haalt-die-adem kwaliteitsporduct een aparte tag met flash neergezet.

Dit kan ik niet helemaal volgen.
Verklaar u nader .

Ai, door emotie overmand stikt het ook nog van de typefouten.
IE 8 herkent <video> niet. Een html-element dat niet wordt herkend door een browser, hoort genegeerd te worden. Alsof het niet bestaat. (Je hoort er wel css aan te kunnen geven, maar dat werkt dus niet in IE 8).
IE 8 negeert <video></video> dus gewoon. Net zoals een lege <div>, zeg maar.
Binnen <video</video> staat echter een <object>. En dat kent IE 8 wel. Binnen dat <object> staat het flash-gebeuren.

Dat is vermoedelijk ook waarom je <video> niet ziet: een onbekend element wordt genegeerd. Dat is volgens de standaard. Maar de css ervoor wordt ook genegeerd, en dat is een hele vervelende fout bij IE 8 en eerder, want daar loop je voortdurend tegenaan.
Je kunt met wat JavaScript ervoor zorgen dat je wél css aan <video> kunt geven (en aan andere elementen die IE 8 niet kent), maar dat is hier nutteloos, omdat er ook geen videospeler in IE 8 zit. En die is nodig voor <video>. Dus in dit geval maakt het weinig uit.

Dit is trouwens ook de reden dat IE door vrijwel alle websitemakers wordt geháát: er worden alleen veiligheidsupdates uitgebracht. Als er een fout in de weergave zit, of iets kan nog niet, tja, jammer dan, dat wordt niet gerepareerd. Dus met elke versie van IE zit je weer tien jaar met een blok aan het been. Elke andere browser wordt gewoon geüpdatet. Waarom IE dat niet doet is iedereen raadsel.

Omdat 't 'n leuk iets is toch al even zitten spelen. Ik denk dat het dodelijk simpel is. Zo simpel, dat het daardoor ingewikkeld wordt. Of zoiets.
Alleen even snel zitten spelen, dus ik garandeer nog nies.
Het doctype moet html5 zijn. Met html 4.01 strict werkt <video> niet goed.
<video> moet gewoon ín de <a>, bij de afbeelding. En dan verbergen met display: none en zichtbaar maken bij hoveren over de afbeelding.
Lijkt te werken in Firefox, Google Chrome en Opera. Rest nog niet geprobeerd.

Eén heel irritant iets: als je niet meer over de afbeelding hovert, verdwijnt de video en komt de afbeelding gewoon weer terug. Maar de video blijft wel spelen. En niet iedereen zal weten waar die video zit. Mede omdat er zes stuks zijn. Zonder geluid is dat trouwens geen probleem, mits het geen grote video's zijn, want anders wordt je gestraft met een waanzinnige download als je elke video 1 seconde bekijkt.
Maar het is mogelijk om de video te pauzeren op het moment dat je de afbeelding verlaat. Daar is wel wat JavaScript voor nodig, maar dat is minimaal.

Op touchscreens heb ik het nog niet geprobeerd, maar ik heb goede hoop dat het op iOS en Android ook werkt.

Goede morgen GB,

Goed je eerste ondervindingen al te horen.
Het DOCTYPE heeft dus wel invloed. En <video> is dus een "lastig" element.
En ik kon het (in sommige gevallen) gewoon niet goed zien/beoordelen wat ik deed.

Dat ik er nu pas achterkom dat mijn "systeem", HTML-KIT in combinatie met XP (IE), etc mij "pootje heeft gelicht".
(ik had dit beter vooraf moeten controleren)
Op een of andere manier komen er (bijna) altijd haken en ogen om de hoek kijken.
(leuk item om eens te visualiseren overigens).

Ik moet nu als de wiedeweerga naar een bijeenkomst en ben rond 13.30 terug op mijn honk.

Grt herman

En vergeet mijn bescheiden bijdrage bij het jou op het verkeerde been zetten ook niet. Het was mijn idee om het zo nodeloos ingewikkeld te maken. Ik heb het ook eerst geprobeerd met 'n negatieve margin-top en zo, en het resultaat leek aardig op 'n vlooiencircus zonder vlooientemmer. Dat zou wel lukken, ooit, maar is hartstikke lastig.

He, he, ik ben terug op de basis.

Nou, jouw bijdrage van het mij op het verkeerde been zetten valt wel mee.

In het begin had ik een basis idee en dat is gaandeweg een beetje veranderd.
Het is net zo als met het maken van een programma (verhaal) of het renderen van een video: Je moet van te voren goed weten wat je eruit wilt krijgen. Weet je dat niet dan is de kans groot dat je al aan de basis "fouten" maakt.

Wat ik wil zeggen is dat ik van te voren (nog) beter had moeten nagaan of ik wel de juiste tools had om een website te maken.
Bvb de combinatie van KT en IE.
Ik heb veel geexperimenteerd en dan is het verdomde handig dat je ook echt ziet wat je doet en wat er mis gaat.
Daarop kun je dan anticiperen.
Toegegeven, de wereld van het website bouwen, en de te gebruiken "talen", zit vol met valkuilen. Neem alleen al de verschillende browsers.
Nee, het is echt een vak.
Hier kunnen anderen misschien wel lering uit trekken.

Ik ben wel heel benieuwd wat er zo nodeloos ingewikkeld was.
Of zou dat te ingewikkeld zijn voor mij ?

Nee hoor. De oorspronkelijke afbeelding staat binnen een <a>. Die <a> en afbeelding heeft al de goede plaats, border, enz.
Mijn idee was om die <video> boven de <a> te zetten. En omdat <video> ruimte inneemt, moet je dan de hele <a> naar boven schuiven. En kom je in 'n gebed zonder end wat betreft marges en padding en ander gedoe. Oftewel: voornoemd vlooiencircus zonder vlooientemmer.
<video> is per definitie even groot als de afbeelding binnen de <a>. Als je nou <video> ook binnen de <a> zet, staat hij automatisch op de juiste plaats. Alleen staan er nu 'n <img> én 'n <video> binnen de <a>, dus wordt de hele handel twee keer zo groot.
Gewoon de <video> standaard verbergen, en bij hoveren over de <a> de <img> verbergen.
En 't leuke is dat dat hoveren eigenlijk al gebeurde. Voor browsers die <video> niet kennen, wordt de achtergrond-afbeelding zelfs nog zichtbaar bij hoveren, want achter <video> verschijnt bij hoveren nog steeds die achtergrond-afbeelding, al zie je die niet.

Terzijde: was dat 'n hinderlaag? Er staat drie keer dezelfde regel div#links a:hover img {display: none;} in de css. Ik heb de eerste uitgecommentarieerd en snapte niet waarom het hoveren bleef werken. Twee van die regels kunnen eruit. Omdat je geen class of zo gebruikt, werkt het gewoon voor élke <img> binnen div#links a

Ik heb wel m'n twijfels over IE 8. Over anderhalf jaar wordt die niet meer ondersteund, dus of dat nog echt de moeite waard is voor 'n extra iets als die video's?
Er zijn twee problemen (en ongetwijfeld nog 87 andere in dat kreng die ik nu vergeet).
* Je hebt 'n video-speler nodig. De meeste (alle?) vragen geld voor commercieel gebruik. Ik vermoed dat, omdat jij ook opdrachten verkoopt, dat onder commercieel wordt verstaan.
* Het is echt nodig dat de video stopt als je niet meer over 'n afbeelding hovert. Bij zes video's is het volstrekt onduidelijk welke wel/niet speelt, dus je bezoekers jaag je gegarandeerd weg. Ik heb al gezien dat dat met <video> vrij simpel is, omdat de api daarvan gestandaardiseerd is. (De api is zeg maar de manier waarop je met in dit geval JavaScript <video> aanstuurt.) Ik ben absoluut geen JavaScript-expert, maar dit lukt zelfs mij, denk ik.
Ongetwijfeld kan 'n goede speler voor IE 8 dat ook, maar dat is 99% zeker geen standaardmanier, dus dat kost waarschijnlijk de nodige moeite om uit te vinden. Bovendien heeft IE 8 nogal wat JavaScript wat afwijkt van de standaard, dus dat is ook al 'n ellende op zich. (IE 9 al veel minder, IE 137 schijnt volledig standaard te worden.)

Als het mijn site zou zijn, zou ik IE 8 laten schieten, denk ik. Over anderhalf jaar is XP echt ten einde en daarmee IE 8 ook.
Eventueel zou je voor IE 8 wat eigen html kunnen maken, waardoor die de video in een apart scherm/iframe/... afspeelt. Maar ik vraag me ernstig af of dat de moeite waard is. De achtergrond-afbeelding verschijnt wel gewoon in IE 8 bij hoveren (denk ik, nog niet getest).
Vanavond ga ik er serieus mee aan de slag. Benieuwd of het gaat lukken.

Bon soir GB,
daarmee wil ik zeggen, het donkert al aardig.

Gewoon de <video> standaard verbergen, en bij hoveren over de <a> de <img> verbergen.
En 't leuke is dat dat hoveren eigenlijk al gebeurde. Voor browsers die <video> niet kennen, wordt de achtergrond-afbeelding zelfs nog zichtbaar bij hoveren, want achter <video> verschijnt bij hoveren nog steeds die achtergrond-afbeelding, al zie je die niet.

Aha, en dat kan technisch? Dat zou geweldig zijn.

En 't leuke is dat dat hoveren eigenlijk al gebeurde.

Je bedoelt dan in de code die er nu al staat.

Terzijde: was dat 'n hinderlaag?

Hoofdzakelijk bedoeld voor mezelf. Het was geloof ik nog een experiment waarin ik probeerde de plaats van de foto's afzonderlijk te manipuleren. Ik wilde de 1e foto hoger in de kolom hebben (dichter bij de onderkant van de logo-container) en de afstand tussen de 1e en de 2e foto en de 2e en de 3e foto iets ruimer hebben. Later alles weer verplaatst en de dubbele code laten staan. Zoiets.
En dat wil ik eigenlijk nog steeds maar dat kan evt. later. Is het dan noodzakelijk om voor elk van de 3 fotos/links in de kolom een aparte class met verschillende margins te maken?

* Je hebt 'n video-speler nodig.

Alleen voor IE 8 bedoel je dan toch?

* Het is echt nodig dat de video stopt als je niet meer over 'n afbeelding hovert.

Helemaal mee eens.

IE 137 schijnt volledig standaard te worden

Klopt, ik meen dat Nostradamus daar nog wat over gezegd heeft.
De originele tekst heb ik niet 123 bij de hand maar zo iets van: "Nadat Laurazie en Gondwana zich uiteindelijk weer hebben samengevoegd in Pangea, in het 137ste eon na the BigBill, zullen de vuurvos en de Intelligente Ontdekker zich uiteindelijk verbroederen.
Tamelijk cryptisch maar vooraanstaande exegeten in deze materie hebben dat althans zo kunnen duiden .

... waardoor die de video in een apart scherm/iframe/... afspeelt

Dan bedoel je op dezelfde pagina die je dan als achtergrond ziet maar dan bovenop (als een soort pop-up?) of zoals ik al eerder had op een nieuwe (blanco) pagina?
De vraag blijft inderdaad of het de moeite waard is. Ik heb geen idee hoeveel mensen (organisaties) nog met IE8 werken. Het is geloof ik wel zo dat je XP niet met IE9 kunt updaten. Dan moet je het hele O.S. vervangen.
Heb ik het goed begrepen dat een (betaalde) mediaplayer dat zou kunnen ondervangen?

Succes vanavond.

Je kunt in principe duizend dingen verbergen/tonen bij hoveren. Dus in principe blijft die achtergrond-afbeelding gewoon werken, los van de video. Dat is de theorie. De praktijk moet wel even worden getest...

Ja, dat hoveren staat al in de huidige code. Er hoeven - hopelijk - eigenlijk alleen twee regeltjes voor <video> bij in de css.

Als je de foto's 'n verschillende marge wilt geven, moeten ze inderdaad een aparte class krijgen. Anders weet de css niet waarvoor het is bedoeld.
Je kunt ook Nadeel hiervan is dat bij 'n wijziging van de html de volgorde ook kan veranderen. Zet 'n <p> tussen twee <a>'s, en a + a is a + p + a geworden.
css3 heeft veel meer mogelijkheden, maar dat werkt niet in zucht IE8. Dus ik zou nog even voor classes (of id's) gaan.

Volgens mij was het trouwens wel 'n test, die dubbele regels. Ben ik geslaagd?

Alleen voor IE 8 heb je 'n video-speler nodig. Sommige video-speler, zoals jwspeler die ik gebruik, kunnen een video afspelen alsof het flash is. Op die manier kan het werken in IE 8. Voor alle andere browsers bij elkaar heb je maar twee andere formaten nodig. Daarmee bestrijk je álle browsers. Helaas konden ze het niet eens worden over één formaat, maar twee valt ook nog wel mee.

Ik vind het wat lastig dat je zo in details treedt over Nostradamus. Dat probeerde ik juist te vermijden. Ik heb het nu maar even nagevraagd bij de opsteller van de Maya-kalender (heb 'n rechtstreeks lijntje), en die verzekert mij dat Nostradamus het bij het verkeerde eind had. Er kómt helemaal geen IE 137. De wereld blijkt te vergaan overmorgen. Dus sorry, ik ga vanavond maar niet aan je site werken. Voor twee dagen is dat niet de moeite.
Wist je trouwens dat de vuurvos en de Intelligente Ontdekker dan ook samen een opera gaan zingen?

Ik bedoelde inderdaad openen in een aparte pagina, of in een aparte pop-up of iframe of zo. En een betaalde player zou dat kunnen ondervangen. Dat is precies wat er bij mij op de site gebeurt. Daar draait IE op dezelfde plaats als de andere browsers. Alleen is dat niet commercieel, dus ik betaal niet. En het automatisch stoppen als niet meer wordt gehoverd kan ook lastig zijn.
Je kunt IE 9 inderdaad niet installeren op XP. Maar XP wordt over anderhalf jaar niet meer ondersteund, dus dan is het heel snel weg. (Je bent hartstikke gek als je 'n niet ondersteund besturingssysteem blijft gebruiken. Of je moet héél kundig zijn.) Maar Opera, Firefox en Google Chrome draaien er prima op.

Hier zijn wat links naar sites die statistieken over o.a. browsers bijhouden. Je moet even bij de knoppen zoeken naar browser, browser version en/of browser version trend. Er zitten forse verschillen in de metingen. w3schools bijvoorbeeld is een site voor makers van sites e.d. Die gebruiken vrijwel geen IE. Dat verklaart de verschillen. Maar bij allemaal zie je 'n sterke daling in het gebruik van IE 8.

Oeps, vergeet ik de links: https://www.css-voorbeelden.nl/links.html#a-stats

Dat gaat helaas toch niet lukken. In theorie zou het moeten werken, in de praktijk niet.
Ik denk dat het probleem is dat <video> nog relatief nieuw is. Ook het plaatsen van dit soort elementen binnen een <a> is relatief nieuw.
Het blijkt onmogelijk te zijn om de weergave in alle veel gebruikte browsers goed te krijgen. Als je gewoon <video> gebruikt voor een grote video, werkt het prima. Maar ik denk dat de combinatie met de plaatsing binnen een <a> enz. problemen geeft.
In Google Chrome en IE 9 krijg ik de video gewoon niet aan de praat. Als ik de hele pagina leeg maak, dan werkt het prima. Dus iets in jouw code botst enorm met <video>, of de plaatsing binnen de <a>, of de border rondom de <a>, of wat dan ook. Deze twee browsers zijn zo'n 40%, dus als het daarin niet werkt...
Als ik dit aan de praat zou willen krijgen, ben ik echt dagen bezig om stap voor stap jouw code terug te zetten in een lege pagina, tot het conflict is gevonden. En dan nog is het de vraag of het is op te lossen, want als het 'n bug is... En in IE worden bugs sowieso nooit gerepareerd.
(Het kost vermoedelijk zoveel tijd, omdat het iets is wat gewoon niet zou mogen gebeuren. Het is geen simpele fout in de css of html. Tijdens het proberen merkte ik bijvoorbeeld, dat Google Chrome het wel afspeelde als je bepaalde code weghaalde in combinatie met het toevoegen in de head van <script src="sinterklaas"></script>. Dat slaat natuurlijk helemaal nergens op, dus dat wijst in de richting van een bug.)

Mobiel was het trouwens nog erger. Opera mobiel gaf bij afspelen een verkleinde weergave van de hele pagina in plaats van de video. Pardon? Ja, serieus. Er was echt niets van de video te zien, maar wel een perfecte miniatuur.
Google Chrome gaf alleen de footer van de pagina weer.
Firefox begon gelijk af te spelen, wat niet hoort.
Android browser crashte gewoon. Wel mooi hoor, 'n zwart scherm, daar niet van. Maar toch geen video.

Ik vind 't echt jammer, want het leek zo'n leuk idee. Je kunt het natuurlijk nog op grotere forums proberen, want als er meer mensen naar kijken, wie weet. Het lijkt op een hele serie bugs e.d. binnen de verschillende browsers. Met 'n beetje geluk heb je op grotere forums mensen die daar al ervaring mee hebben.

Ik heb nog wel wat kleine dingetjes gevonden op andere terreinen.

Het dropdownmenu werkt goed in Android 2.1 en 4.0 en in iOS (iPad e.d.).
In Android sluit het menu als je naar 'n pagina gaat, of als je buiten het menu ergens het scherm aanraakt.
In iOS sluit het menu niet, het blijft altijd open. Dat kun je oplossen door te veranderen in Die onclick hoort eigenlijk niet in de html, dat is een verouderde manier van coderen. Maar hier kan het geen kwaad. Er staat namelijk, dat het ding helemaal niets moet doen: bij klikken (onclick) niets doen (="") En dan kan het geen kwaad in de html.
Het menu reageert op een aanraking, omdat het in allemaal <a>'s zit. Met die onclick geef je de opdracht dat div#main_container óók moet reageren op een klik, op aanraken. En verder niets doen, vooral niets doen. Maar dit zorgt ervoor dat de focus van het menu wordt afgehaald, waardoor dit sluit.
En omdat de hele pagina, behalve de footer, binnen div#main_container staat, werkt die aanraking overal.
Eventueel kun je ook nog aan div#footer_container die onclick="" toevoegen, maar ik denk niet dat veel mensen via de footer het menu sluiten.

Als je klikt op dat diafragma in het midden, wordt een afbeelding geopend in een nieuw venster. Dat lijkt me niet de bedoeling. Als je ->
verandert in dan werkt het hoveren nog steeds, maar de link werkt niet meer. Bij per ongeluk klikken opent geen nieuw venster.
(Misschien is dat trouwens wel de bedoeling, maar dan mis ik kennelijk iets.)

Eventueel kun je in de css aangeven dat de cursor boven het diafragma niet in een handje verandert, want dat hoort eigenlijk bij een link. Als je verandert in blijft de cursor gewoon de standaardcursor boven het diafragma.

En nou ben ik even uitgekeken op al die apparaten.

Da's jammer. Echt jammer.
En een ander forum, ik weet het niet...
En als jij het niet kunt oplossen ga ik er niet eens 'ns naar kijken.

Het heeft dus te maken dat het <video> element niet goed werkt op mijn site.
Of is het ook de combinatie van voorgrondfoto, achtergrondfoto en daarna het afspelen van de video?
Wat mij betreft kan ook een van de foto's eruit.
Jammer, want ik vind het een leuk effect maar de video (dwz een effect van max. 10 sec. dwz dus 6x en ook de "trial" (iets langer) onder het diafragma) is belangrijker.

Ik ga morgen je opmerkingen, etc goed doorlezen.
Het was vandaag een zware dag en ik ben "total loss".
Alvast bedankt voor het proberen. Ik "zie" je morgen.
Misschien dat als ik het doorgelezen heb op een ander idee kom.

Wel nog even een biertje.
En wat muziek.

Slaap goed,
Herman

Ha, maar nou wordt het een erekwestie. Dat het niet zou kunnen, vind ik geen probleem. Maar dan wil ik toch wel weten waarom.
En aangezien ik in de gelukkige omstandigheid verkeer dat ik zelf m'n tijd kan indelen...
Kortom: ik ga toch 'ns stap voor stap proberen te kijken waar het probleem zit. Al zal dat dus wel even duren. Het zou kunnen dat het gelijk vrij snel duidelijk is: <video> werkt gewoon niet goed in combinatie met display: none;, bijvoorbeeld. Dat wordt dan snel duidelijk.
Ik ga het omgekeerd doen. Ik begin met een totaal lege pagina met alleen video (en de head en zo). Dat werkt. En dan ga ik stukje voor stukje jouw code erbij zetten, en stukje voor stukje de css. Tot ik zie waar het misgaat.
Wie weet is dat inderdaad die tweede foto. Dat zou dan duidelijk worden. Ik heb jouw idee ook nog nergens gezien. Tot nu toe heb ik alleen rechttoe rechtaan <video>'s gezien.

Hoi GB,

Ik heb geslapen als een os. En een goede nachtrust is de basis voor een heldere blik. Tenminste... dat was vanmorgen.
Eerst even een goed bericht: De gemeente heeft groen licht gegeven om mijn bedrijfsplan verder te ontwikkelen en zijn evt bereid het te steunen.

Ik heb je commentaar en je nieuwe bericht gelezen. Je geeft het nog niet op. Een erekwestie. Dan wordt het dus menens.
Oke, maar ik sta behoorlijk bij je in het krijt.

Als je gewoon <video> gebruikt voor een grote video, werkt het prima. Maar ik denk dat de combinatie met de plaatsing binnen een <a> enz. problemen geeft.

Een stuk minder mooi maar dat zou dan nog een optie kunnen zijn. Bij klikken verschijnt een nieuwe pagina (die is evt zwart te maken lijkt me) en daar verschijnt dan de video. Maar is dan, vanwege de datastroom, een klein formaat (videovenster) mogelijk?

Dat slaat natuurlijk helemaal nergens op, dus dat wijst in de richting van een bug.)

Een bug in Google Chrome...

(Misschien is dat trouwens wel de bedoeling, maar dan mis ik kennelijk iets.)

Nee, dat was niet de bedoeling.
Die "#" had ik er in gezet (ook bij de kolomfoto's) om later de link naar de video te kunnen maken. Maar daarvan is al duidelijk geworden dat het niet de goede methode is.

En de andere "kleine dingetjes" lijken me duidelijk en zijn weer een verdere perfectionering.

Ik hoop dat je een oplossing kunt vinden. De voorbeeld video's zijn belangrijk, dat wist je al. Daarom mag van mij, als het niet kan, dat hele gedoe met muisover ook vereenvoudigd worden. Maar ik heb begrepen dat zelfs de plaatsing momenteel lastig is met het element <video>.
Als het probleem in "mijn" html/css zit is het "natuurlijk" op te lossen maar als het bugs zijn in de browsers ... is het niet haalbaar (momenteel).

En doe geen moeite voor IE8.

groet, herman