Det var ikke fordi, jeg antog dig for at være ironisk. Jeg syntes blot, det så ud somom du havde misforstået noget - og det bekræftede din kommentar:
"Jeg er bare enig med dig i at det er den bedst mulige måde i det, hvis man ikke bruger CSS i resten af sit dokument"
Nej ... det er _måden_ at løse problemet på - uanset hvormeget CSS du ellers bruger i dokumentet. I stedet for at sætte line-height og font-size kan du dog også gemme overflow via CSS - men det har stadig ikke noget at gøre med yderligere brug af CSS eller ej.
Ubrugelig, invalid kode er så sandelig ikke ligemeget ... tværtimod, det kan være katastrofalt!
Hvis man bruger en fuld DTD og kender de steder, hvor IE renderer med små-fejl, er der derimod ikke de store problemer med IE's fejl-visninger - og så har FF jo altså også renderingsfejl ;o)
Prøv til gengæld denne kode:
<script type="text/JavaScript">
function foo() {
var im, o = document.getElementById("gnu");
im = document.createElement("img");
im.setAttribute("src", "
http://www.eksperten.dk/img/elogo.png");
o.appendChild(im);
alert(document.body.innerHTML)
alert(im.parentNode.nodeName)
}
</script>
<input id="gnu" type="text">
<button onclick="foo()">TEST</button>
Læg mærke til de to alerts! De viser, at ikke engang FF selv har en kæft anelse om, hvad den har lavet. Selvom innerHTML'en fortæller noget andet, ligger billedet faktisk indlejret i input-elementet - hvilket burde være en komplet umulighed!
Denne kode er da også interessant:
<script type="text/JavaScript">
function foo() {
var im, o = document.getElementById("gnu");
im = document.createElement("img");
im.setAttribute("src", "
http://www.eksperten.dk/img/elogo.png");
o.appendChild(im);
alert(document.body.innerHTML)
alert(im.parentNode.nodeName)
}
</script>
<select>
<option>ghnfgh</option>
<option id="gnu">ghnfgh</option>
<option>ghnfgh</option>
<option>ghnfgh</option>
</select>
<button onclick="foo()">TEST</button>
- og jeg kunne blive ved. Lægge en hel tabel ind i title-elementet - eller i et meta-element i haed'en. Eller hvad med at klone hele documentElement-elementet og append'e det til et option-element ...!!!
Problemet er, at DOM bliver ekstremt vigtigt i forbindelse med det såkaldte Web2.0 - herunder Ajax, som DOM-manipulation er en uadskillelig, nødvendig del af.
Er en browser ikke god til DOM, har jeg svært ved at se dens fremtidige relevans på et WWW, hvor DOM bliver mere og mere benyttet/nødvendigt.
Bevares ... man kunne jo argumentere for, at kodere bare kunne lade være med at foretage den slags tåbelige appends.
Ja, men det er til gengæld ekstremt væsentligt, når man skriver komplekse web-applikationer, at man kan teste 'det næste' element - uanset hvor i DOM'en man står ... kan det indeholde elementer eller ej?
Hvis browserens DOM fungerer kan man teste den slags i en try/catch - men det er komplet udelukket, når browseren er FF, hvorfor man ofte må gå enorme omveje, når man scripter mod DOM'en.
Som et lille kuriosum har Mozilla ovenikøbet indført innerHTML-property'en i FF's XHTML-DOM - på trods af, den aldrig har været del af nogen officiel standard ... og nærmest er en rallende vittighed i forhold til XHTML og meningen med W3C's XML-DOM.
Endnu mere sært er det, at den blot er en skidt klon af den i forvejen yderst buggy innerHTML-property fra HTML-DOM laget i FF (se eksemplerne ovenfor).
Det ærgelige er, at hverken Netscape6 eller 7 - eller for den sags skyld Mozilla 1.5 - havde disse (og mange flere) fejl. Det er først efter, man releasede FF, skidtet er blevet så elendigt og fejlfyldt.
Endnu mere ærgeligt er det, at der aldrig bliver rettet noget, når folk i én uendelighed messer mantraene om FF's 'vidunderligheder'. Sålænge folk ikke vil høre sandheden om FF's tilstand, må vi nok se i øjnene, den ikke bliver bedre ... man kan jo ikke forbedre på en browser, der ikke _må_ have fejl :o|
Ja, IE er en rigtig skidt browser - men det er Firefox også. Det er bare synd, folk ikke har viden og/eller mod nok til at gå mod strømmen af lemminger!
