[JS] Lightbox werkt niet via IE

[Verwijderd]

Ik ben een amateur wat betreft Javascript, dus misschien dat iemand anders mij hier kan helpen. Ik heb voor mijn portfolio een Lightbox-script gebruikt, maar alleen met Firefox werkt hij goed. In IE wordt mijn hele pagina zwart, terwijl mijn portfolio nog wel werkte voordat ik het scriptje toegevoegd heb.

Een voorbeeld hier..

Weet iemand wat er niet klopt?

[Verwijderd]

HTML:

<script type="text/JavaScript" src="script.js" />

Kan IE niet tegen. Maak er <script type="text/javascript" src="..."></script> van.

[Alex)]

En bedankt, IE wil die tab nu niet meer sluiten...

Edit:

HTML:

        <script type="text/JavaScript" src="script.js" />
        <script type="text/javascript" src="js/prototype.js" />
        <script type="text/javascript" src="js/scriptaculous.js?load=effects" />
        <script type="text/javascript" src="js/lightbox.js" />

Vindt IE inderdaad niet zo leuk, je moet gewoon <script>...</script> gebruiken, het is tenslotte geen <img>-tag...

[ Voor 79% gewijzigd door Alex) op 13-01-2007 17:32 ]

[Verwijderd]

Verwijderd schreef op zaterdag 13 januari 2007 @ 17:26:

HTML:

<script type="text/JavaScript" src="script.js" />

Kan IE niet tegen. Maak er <script type="text/javascript" src="..."></script> van.

Bedankt voor je reply!

Maar, als ik dat in </script> verander gaat mijn doctype niet meer op..het is verplicht dat ik XHTML 1.0 Strict moet gebruiken. Is er geen andere oplossing voor dit probleem? (Misschien een domme vraag hoor, maar hoezo geeft IE geen problemen bij een "/>" afsluiting in het geval van mijn css?)

[Verwijderd]

</script> is gewoon XHTML1.0 Strict hoor. XHTML verplicht je je tags te sluiten, dus <p></p>, <img /> en <script></script>.

[Alex)]

Waarom gebruik je XHTML 1.0 Strict? Tenzij je je pagina's verzend als text/xhtml+xml heb je hier niks aan, je bent dan beter af met HTML 4.01 Strict (of Transitional)

[Verwijderd]

@DOT: als ik de Java tags zo sluit, komt hij niet meer door de validator. Kijk:
This page is not Valid XHTML 1.0 Strict!

Below are the results of checking this document for XML well-formedness and validity.

1. Error Line 10 column 49: unclosed start-tag requires SHORTTAG YES.

<script type="text/JavaScript" src="script.js" </script>

✉
2. Error Line 11 column 55: unclosed start-tag requires SHORTTAG YES.

<script type="text/javascript" src="js/prototype.js" </script>

✉
3. Error Line 12 column 72: unclosed start-tag requires SHORTTAG YES.

...ript" src="js/scriptaculous.js?load=effects" </script>

✉
4. Error Line 13 column 54: unclosed start-tag requires SHORTTAG YES.

<script type="text/javascript" src="js/lightbox.js" </script>


En ik meen mij te herinneren dat in mijn HTML-boek staat dat in XHTML de tags als volgt gesloten moeten worden: " />".

@Alex): Ik moet voor mijn studie mijn portfolio in XHTML 1.0 Strict maken.


Excuses voor mijn kennis hierover, dit is namenlijk mijn 1e pagina pas in html.

[ Voor 5% gewijzigd door Verwijderd op 13-01-2007 17:55 ]

[Verwijderd]

Verwijderd schreef op zaterdag 13 januari 2007 @ 17:35:
[...]

Bedankt voor je reply!

Maar, als ik dat in </script> verander gaat mijn doctype niet meer op..het is verplicht dat ik XHTML 1.0 Strict moet gebruiken. Is er geen andere oplossing voor dit probleem?

Het document wordt toch al verzonden als text/html, dus XHTML is het sowieso niet. Hoe kom je erbij dat met </script> het geen XHTML meer zou kunnen zijn? XML shorthand is niet verplicht voor zover ik weet.

(Misschien een domme vraag hoor, maar hoezo geeft IE geen problemen bij een "/>" afsluiting in het geval van mijn css?)

Omdat <link/> tags toch nooit childNodes of textNodes hebben. Zelfde geldt voor <img/> en <input/>, etc.

Verwijderd schreef op zaterdag 13 januari 2007 @ 17:54:
1. Error Line 10 column 49: unclosed start-tag requires SHORTTAG YES.
<script type="text/JavaScript" src="script.js" </script>

Ligt het nou aan mij of ben je een > vergeten voor </script>?

@Alex): Ik moet voor mijn studie mijn portfolio in XHTML 1.0 Strict maken.
Excuses voor mijn kennis hierover, dit is namenlijk mijn 1e pagina pas in html.

Geen excuses nodig, je doet het niet slecht. Als het echt XHTML 1.0 strict moet zijn moet het zoals Alex) al schreef ook met de juiste content-type worden verstuurd. Echter, dan zal IE helemaal er de brui aan geven... IE is gewoon niet XHTML-compatible.

[ Voor 33% gewijzigd door Verwijderd op 13-01-2007 18:02 ]

[Alex)]

code:

<script type="text/javascript" src="js/lightbox.js"> </script>

is wél goed, je was simpelweg de > vergeten.

Slecht trouwens, dat je per sé in XHTML 1.0 Strict moet werken, XHTML heeft momenteel helemaal geen voordelen t.o.v. 'gewone' HTML 4.01 Strict, alleen maar nadelen doordat de browser een extra vertaalslag moet maken (van XHTML naar HTML-complaint-tags voor de interne voorstelling en rendering).

[ Voor 5% gewijzigd door Alex) op 13-01-2007 17:58 ]

[apokalypse]

Verwijderd schreef op zaterdag 13 januari 2007 @ 17:54:
@DOT: als ik de Java tags zo sluit, komt hij niet meer door de validator. Kijk:
This page is not Valid XHTML 1.0 Strict!

Below are the results of checking this document for XML well-formedness and validity.

1. Error Line 10 column 49: unclosed start-tag requires SHORTTAG YES.


<script type="text/JavaScript" src="script.js" </script>

✉
2. Error Line 11 column 55: unclosed start-tag requires SHORTTAG YES.

<script type="text/javascript" src="js/prototype.js" </script>

✉
3. Error Line 12 column 72: unclosed start-tag requires SHORTTAG YES.

...ript" src="js/scriptaculous.js?load=effects" </script>

✉
4. Error Line 13 column 54: unclosed start-tag requires SHORTTAG YES.

<script type="text/javascript" src="js/lightbox.js" </script>


En ik meen mij te herinneren dat in mijn HTML-boek staat dat in XHTML de tags als volgt gesloten moeten worden: " />".

@Alex): Ik moet voor mijn studie mijn portfolio in XHTML 1.0 Strict maken.


Excuses voor mijn kennis hierover, dit is namenlijk mijn 1e pagina pas in html.

je moet wel
<script type="text/JavaScript" src="script.js" ></script>
doen ipv
<script type="text/JavaScript" src="script.js" </script>

edit: te laat

[Leedbek]

Verwijderd schreef op zaterdag 13 januari 2007 @ 17:54:
<script type="text/JavaScript" src="script.js" </script>

Dit kan natuurlijk niet. Je bent de afsluitende ">" vergeten in je <script> tag.
Oftewel:
<script type="text/JavaScript" src="script.js"></script>

edit:
Spuit 11

Off-topic: je doet zeker Kunst en Techniek, aan je portfolio te zien. Leuk, een medestudent

[ Voor 15% gewijzigd door Leedbek op 13-01-2007 18:01 ]

[Verwijderd]

Luuk-Online schreef op zaterdag 13 januari 2007 @ 17:59:
[...]
Off-topic: je doet zeker Kunst en Techniek, aan je portfolio te zien. Leuk, een medestudent

Haha klopt

En oja, het werkt trouwens.. bedankt iedereen

[ Voor 10% gewijzigd door Verwijderd op 13-01-2007 18:15 ]

[Verwijderd]

Je hebt wel wat aan XHTML, maar natuurlijk niet als je het als text verstuurt. Als je webserver een php-interpreter aan boord heeft, en je verandert je *.html bestanden in *.php bestanden, dan kan je er even

PHP:

<?php
header('Content-Type:application/xhtml+xml;charset:iso-8859-1');
echo '<?xml version="1.0" encoding="iso-8859-1" ?>' . "\n";
?>

voor plakken. Hierdoor zal de browser de pagina sneller kunnen parsen, omdat de fout-afhandeling simpeler is (hij errort gewoon keihard als hij een fout tegenkomt). Andere voordelen zitten hem in de mogelijkheid tot het gebruik van MATHML, xml-blokken, en in de toekomst misschien nog andere dingen.

Hét nadeel is dat IE6 er niks van snapt. IE7 misschien zelfs niet. Dus zal je de site toch als text/html moeten serveren voor IE. Dit kan je doen met de code van Keystone Websites.

Maar dan zal je dus ook moeten nadenken over IE-hacks voor MATHML, dus eigenlijk kan je door onze grote vriend Microsoft nog niet echt gebruik maken van XHTML.

[Verwijderd]

de reden dat het fout gaat is juist dat het geen xhtml is maar html (want als html verstuurd) en dan wordt <script /> gewoon gelezen als <script> en is dus fout, want het element heeft een verplichte sluittag.

Als je het als xhtml verstuurt gaat het wel goed, tenminste in browsers die xhtml snappen, waar IE dus niet onder valt.

je doctype is dus feitelijk fout, je document is html

(Misschien een domme vraag hoor, maar hoezo geeft IE geen problemen bij een "/>" afsluiting in het geval van mijn css?)

Omdat <link/> tags toch nooit childNodes of textNodes hebben. Zelfde geldt voor <img/> en <input/>, etc.

nee, omdat het link element geen verplichte sluittag heeft (forbidden) net als img. <link/> en <img/> die in html als <link> en <img> worden gelezen is dus niks mis mee.

als je voor je studie xhtml moet doen, zal de docent neem ik aan ook wel snappen dat het niet in IE werkt (ander mag je zeggen dan mophor vindt dat ie een prutsdocent is )

[ Voor 53% gewijzigd door Verwijderd op 14-01-2007 12:08 ]

[crisp]

Verwijderd schreef op zaterdag 13 januari 2007 @ 20:55:
voor plakken. Hierdoor zal de browser de pagina sneller kunnen parsen, omdat de fout-afhandeling simpeler is (hij errort gewoon keihard als hij een fout tegenkomt). Andere voordelen zitten hem in de mogelijkheid tot het gebruik van MATHML, xml-blokken, en in de toekomst misschien nog andere dingen.

draconical error-handling is geen voordeel maar een nadeel. Ook gaat het punt van 'sneller renderen' niet echt op: een HTML parser kan incrementeel renderen, een XML parser niet.

Verder zal een nieuwe versie HTML ws ook gewoon mogelijkheden bieden tot het mixen met XML-applications zonder dat het document zelf een XML-application hoeft te zijn. XHTML heeft geen toekomst, XHTML2.0 is al een grote mislukking en W3C begint dat nu gelukkig zelf ook in te zien...

Hét nadeel is dat IE6 er niks van snapt. IE7 misschien zelfs niet. Dus zal je de site toch als text/html moeten serveren voor IE. Dit kan je doen met de code van Keystone Websites.

Maar dan zal je dus ook moeten nadenken over IE-hacks voor MATHML, dus eigenlijk kan je door onze grote vriend Microsoft nog niet echt gebruik maken van XHTML.

Als je je document dus blijkbaar ook gewoon als HTML kan versturen dan snap ik ueberhaupt niet waarom je voor XHTML zou kiezen. Het is niet stricter, het is niet nieuwer en het is niet semantischer. Stuur dan gewoon naar alle browsers gewoon HTML ipv nodeloos moeilijk te doen.

[Verwijderd]

crisp schreef op zondag 14 januari 2007 @ 13:33:
[...]

draconical error-handling is geen voordeel maar een nadeel.

Vertel dat maar eens aan C++-compiler-bouwers. Als je foute code maakt, dan wil je dat gewoon zo hard mogelijk in je gezicht geduwd krijgen.

Ook gaat het punt van 'sneller renderen' niet echt op: een HTML parser kan incrementeel renderen, een XML parser niet.

Bedoel je daarmee dat de browser alvast begint te renderen voordat het hele document binnen is? Want dan krijg je van die leuke verspringende elementen als bepaalde dingen nog niet ingeladen zijn. Lijkt me nou niet bepaald wenselijk.

Verder zal een nieuwe versie HTML ws ook gewoon mogelijkheden bieden tot het mixen met XML-applications zonder dat het document zelf een XML-application hoeft te zijn. XHTML heeft geen toekomst, XHTML2.0 is al een grote mislukking en W3C begint dat nu gelukkig zelf ook in te zien...


[...]
Als je je document dus blijkbaar ook gewoon als HTML kan versturen dan snap ik ueberhaupt niet waarom je voor XHTML zou kiezen. Het is niet stricter, het is niet nieuwer en het is niet semantischer. Stuur dan gewoon naar alle browsers gewoon HTML ipv nodeloos moeilijk te doen.

Als je makkelijk wiskundige formules wil renderen, dan zou je kunnen kiezen voor MathML. Dat kan niet in HTML.

Daarentegen ben ik het met je eens dat je nu beter gewoon HTML 4.01 Strict kan gebruiken. Maar als in de toekomst HTML5 en XHTML2 beide door alle major browsers ondersteund worden, dan zou ik toch eerder kiezen voor XHTML2.

[Verwijderd]

Verwijderd schreef op zondag 14 januari 2007 @ 15:16:

Vertel dat maar eens aan C++-compiler-bouwers. Als je foute code maakt, dan wil je dat gewoon zo hard mogelijk in je gezicht geduwd krijgen.

Een script dat door een client uitgevoerd wordt is wel even iets anders he. Alleen de developer hoeft die keiharde foutmeldingen te krijgen.

Bedoel je daarmee dat de browser alvast begint te renderen voordat het hele document binnen is? Want dan krijg je van die leuke verspringende elementen als bepaalde dingen nog niet ingeladen zijn. Lijkt me nou niet bepaald wenselijk.

Zoveel last heb je er kennelijk niet van gehad. In de tijd van de trage inbelmodems was het al niet zo'n probleem, tegenwoordig al helemaal niet. Snelle verbindingen, snelle processoren, dat gaat allemaal als een tiet.

[Verwijderd]

Verwijderd schreef op zondag 14 januari 2007 @ 15:23:
[...]

Een script dat door een client uitgevoerd wordt is wel even iets anders he. Alleen de developer hoeft die keiharde foutmeldingen te krijgen.

Daar ben ik het niet mee eens. Als alleen de developer eventuele errors te zien krijgt, en dan ook alleen maar als hij een speciale parser gebruikt, dan stimuleert dat lakse code.

Zoveel last heb je er kennelijk niet van gehad. In de tijd van de trage inbelmodems was het al niet zo'n probleem, tegenwoordig al helemaal niet. Snelle verbindingen, snelle processoren, dat gaat allemaal als een tiet.

In die tijd had je ook nog geen CSS. Tegenwoordig kan iets dat onderaan het document staat, bovenaan gerenderd worden.

[BasieP]

Verwijderd schreef op zondag 14 januari 2007 @ 15:34:

In die tijd had je ook nog geen CSS. Tegenwoordig kan iets dat onderaan het document staat, bovenaan gerenderd worden.

ik denk dat je hier iets onderschat tot wanneer mensen nog 'trage inbel modems' gebruikte.
ikzelf zat zo'n 6 jaar terug bij rendo dekooi. toen was er echt niks beters bij mij in de buurt en ik mocht blij zijn als ik de 9kb/s haalde..
en ja, toen was er al css

[crisp]

Verwijderd schreef op zondag 14 januari 2007 @ 15:16:
[...]
Vertel dat maar eens aan C++-compiler-bouwers. Als je foute code maakt, dan wil je dat gewoon zo hard mogelijk in je gezicht geduwd krijgen.

Een markup-language is heel wat anders dan een programming language. Bedenk daarbij ook dat error-correction gewoon gedefinieerd kan zijn (en is in WA1.0 aka HTML5)

[...]
Bedoel je daarmee dat de browser alvast begint te renderen voordat het hele document binnen is? Want dan krijg je van die leuke verspringende elementen als bepaalde dingen nog niet ingeladen zijn. Lijkt me nou niet bepaald wenselijk.

Dat verspringen valt over het algemeen best wel mee, zeker als je voor bijvoorbeeld plaatjes alvast de juiste dimensies opgeeft.

[...]
Als je makkelijk wiskundige formules wil renderen, dan zou je kunnen kiezen voor MathML. Dat kan niet in HTML.

Maar mogelijk wel in een nieuwe HTML versie.

Daarentegen ben ik het met je eens dat je nu beter gewoon HTML 4.01 Strict kan gebruiken. Maar als in de toekomst HTML5 en XHTML2 beide door alle major browsers ondersteund worden, dan zou ik toch eerder kiezen voor XHTML2.

Browservendors staan niet bepaald te springen om XHTML2.0 te implementeren. Persoonlijk zie ik het ook nooit gebeuren...

[Verwijderd]

crisp schreef op zondag 14 januari 2007 @ 16:01:
[...]
Een markup-language is heel wat anders dan een programming language. Bedenk daarbij ook dat error-correction gewoon gedefinieerd kan zijn (en is in WA1.0 aka HTML5)

Een markup-language komt in een aantal dingen overeen met een programming language: de 'verwerker' genereert uit beide output en beide hebben een standaard waaraan voldaan moet worden aangezien er verschillende 'verwerkers' zijn. Als fout-correctie gedefinieerd is, dan hoef je het eigenlijk niet eens meer fout te noemen. De taal is dan gewoon uitgebreid met onlogische regels. Dat zorgt voor onleesbare code, rare bugs en een langere parse-tijd.

---

BasieP schreef op zondag 14 januari 2007 @ 15:37:
[...]

ik denk dat je hier iets onderschat tot wanneer mensen nog 'trage inbel modems' gebruikte.
ikzelf zat zo'n 6 jaar terug bij rendo dekooi. toen was er echt niks beters bij mij in de buurt en ik mocht blij zijn als ik de 9kb/s haalde..
en ja, toen was er al css

Als je een trage verbinding hebt, 33k ofzo (wat waren de snelheden ook alweer?), dan heb je voordeel van incremential rendering, omdat je dan al kan gaan lezen terwijl de pagina nog een minuutje aan het laden is.

Als je een snelle verbinding hebt, dan wordt dat een stuk minder belangrijk. Dan wil je gewoon dat je pagina statisch is en zo snel mogelijk geladen is. Het niet verspringen van de layout wordt dan belangrijker dan een milliseconde eerder kunnen beginnen met lezen.

[ Voor 37% gewijzigd door Verwijderd op 14-01-2007 16:26 . Reden: op stukje van BasieP gereageerd ]

[crisp]

Verwijderd schreef op zondag 14 januari 2007 @ 16:18:
[...]

Een markup-language komt in een aantal dingen overeen met een programming language: de 'verwerker' genereert uit beide output en beide hebben een standaard waaraan voldaan moet worden aangezien er verschillende 'verwerkers' zijn.

Een markup language is geen verwerker die output genereert. Het is een taal die content voorziet van een referentiekader aka semantiek. Het doel is de toegankelijkheid te vergroten, en dat bereik je niet door bij de kleinste syntax-fout een geel scherm met 'error!' te laten zien.

Als fout-correctie gedefinieerd is, dan hoef je het eigenlijk niet eens meer fout te noemen.

Toch wel, het voldoet formeel immers niet aan de syntax. Een parser zou dergelijke errors dan ook altijd moeten melden (dat is overigens ook al een aanbeveling voor HTML4).

De taal is dan gewoon uitgebreid met onlogische regels.

contradictus in terminus; als er ergens een regel voor is is het niet meer onlogisch.

Dat zorgt voor onleesbare code, rare bugs en een langere parse-tijd.

Ook niet waar; zolang de regels voor error-correctie zelf niet ambiguous zijn zal een correcte implementatie daar ook niet snel de fout in gaan. Ook is de tijd noodzakelijk voor het 'recoveren' van een syntax error niet of nauwelijks van invloed vergeleken met het tokenisen en parsen van een correct document.

Misschien moet je zelf eens kijken hoe die regels opgesteld zijn in WA1.0

[Verwijderd]

crisp schreef op zondag 14 januari 2007 @ 16:31:
[...]
Een markup language is geen verwerker die output genereert. Het is een taal die content voorziet van een referentiekader aka semantiek. Het doel is de toegankelijkheid te vergroten, en dat bereik je niet door bij de kleinste syntax-fout een geel scherm met 'error!' te laten zien.

Misschien waar, maar praktisch komt het er op neer dat veel amateur-developers denken "ach, het werkt ongeveer".

[...]
contradictus in terminus; als er ergens een regel voor is is het niet meer onlogisch.

Non sequitur; dat iets aan regels gebonden is betekent niet dat het logisch is. In strikte zin kan je het misschien als 'logica' beschouwen, maar dan zouden IE6's browserbugs ook logisch zijn, aangezien het toch echt deterministische C++-regels zijn.

[...]
Ook niet waar; zolang de regels voor error-correctie zelf niet ambiguous zijn zal een correcte implementatie daar ook niet snel de fout in gaan. Ook is de tijd noodzakelijk voor het 'recoveren' van een syntax error niet of nauwelijks van invloed vergeleken met het tokenisen en parsen van een correct document.

Dat neem ik van je aan.

Misschien moet je zelf eens kijken hoe die regels opgesteld zijn in WA1.0

Zal ik vanavond doen.