När man kodar på standardvis dvs följer webbstandard så gäller det att separera funktionalitet från struktur och presentation. Då är det enda javaskript man ska behöva se i ett HTML-dokument är detta:
I praktiken och när du validerar spelar det ingen roll om det ligger i style="" eller klasser/id.
Samma med javascript, du kan lika gärna skriva det i klartext
<script type="text/javascript">
// kod här
</script>
Däremot kan det vara bra att separera den här koden från dokumentet för att få en bättre överblick, samt att det blir enklare att ändra strukturen/designen.
Du slipper alltså ha samma uppsättning kod i flera filer.
Hmm...
Det man får vara noga med när man pratar XHTML är att inte använda tecknen "<" eller "&" i Javascriptkoden eftersom dessa har speciell betydelse i XHTML (via grundkrav som ställs på alla XML-dokument).
... Vilket väl egentligen är orsaken till rådet att bara använda externa Javascriptfiler om men kör XHTML (separeringen av beteenden som webbebba nämner är iofs ett bra skäl, men kanske inte det mest akuta ;) )
... och ja, det gäller även 1.0 Transitional
... det där med kommentarstecknen <!-- och --> i <script> och <style> är inte garanterat att fungera när man serverar sin XHTML enligt konstens alla regler (dvs "som XML") eftersom kommentarer i XML-kod inte garanterat hamnar i den inlästa kodens interna representation ("DOM-trädet") - och därför gör det att det inte är rekommendabelt att ha med dem i "bakåtkompatibel XHTML" (XHTML serverad "som HTML") heller.
- typ
Att det sedan funkar "i praktiken" när man skickar XHTML som HTML är det ingen diskussion om, men då bryter man s.a.s. ganska lätt sönder just XHTML-aspekten av HTML, och då har man enligt min enkla mening valt bort en av grundorsakerna till att använda XHTML till att börja med (nämligen den att man skall kunna hantera sin kod med XML-verktyg om man behöver)
Red: Ack ja - jag tror nog de flesta förstår vad jag menar ändå :OO
Den talar om för en XML-tolk att det som följer är "character data" och ger som följd att allt mellan <![CDATA[ och ]]> (som inte är en del av just strängen "]]>") även får innehålla tecken som annars skulle ha haft speciell betydelse (som t.ex. "<" och "&") i löptext.
Mellan <![CDATA[ och ]]> tolkas alltså inte <b>fet</b> som elementet <b> med innehåll "f", "e" och "t" utan som teckensekvensen "<", "b", ">", "f", "e", "t", "<", "/" "b" och ">" (och det är en rejäl skillnad det i XML ;) )
... Men det där behöver man inte tänka på om man kör med externa Javascript- och CSS-filer - vilket naturligtvis är en bidragande orsak att så många rekommenderar folk att separera sin kod :)
Exemplet som Simon visar upp kommenterar alltså bort <![CDATA[ med respektive språks egna kommentarer för att inte Javascript- respektive CSS-tolken i webbläsaren skall få för sig att tolka dem som kod - samtidigt som de kommer att kunna läsas "som det var tänkt" av en XML-tolk och därigenom tillåta t.ex. "<" i en Javascriptjämförelse. (jfr hur man använder "//-->" som avslutare om man kör kommentarsteckeninramad Javascriptkod - det är samma princip, i princip :)
När man kodar på standardvis dvs följer webbstandard så gäller det att separera funktionalitet från struktur och presentation. Då är det enda javaskript man ska behöva se i ett HTML-dokument är detta:
För att göra koden enklare bör ändra dina funktioner till att vara endast en, och sedan skickar de variabler (fönsterbredd/-höjd, olika egenskaper (meny, statusrad, scroll etc)) du behöver i funktionsanropet.
En sådan funktion kan göras på x antal sätt, ett gott urval finns i javascript-forumet.
För att göra koden enklare bör ändra dina funktioner till att vara endast en, och sedan skickar de variabler (fönsterbredd/-höjd, olika egenskaper (meny, statusrad, scroll etc)) du behöver i funktionsanropet.
En sådan funktion kan göras på x antal sätt, ett gott urval finns i javascript-forumet.
oki... skall söka... MEN måste erkänna att jag inte riktigt förstår vad du menar :q
Som webbebba skrev; den enda javascript kod man ska behöva se är <script> elementet. I ditt exempel har du skriptkod även i <a href- attributet.
Här är ett inlägg som visar ett exempel på hur man kan göra: http://www.webforum.nu/showthread.php?t=117902
...
En sådan funktion kan göras på x antal sätt, ett gott urval finns i javascript-forumet.
Det jag menar är att du använder något liknande detta.
function cw(sida,sidnamn,settings,w,h){
//funktion för att centrera fönster. J.N. 7/5-02
var xMax = screen.width;
var yMax = screen.height;
var xOffset = (xMax - w)/2
var yOffset = (yMax - h)/2;
var oppna = window.open(sida,sidnamn,settings + ',width=' + w +',height=' + h +',top='+yOffset+',left='+xOffset+'');
//tillagt 3/9-02: kontrollera om focusfunctionen finns, sätt då focus på fönstret
//tillagt 21/10-05: oppna &&, så de med popupblockerare slipper felmeddelanden, enligt wF Peter S.
if(oppna && oppna.window.focus){
oppna.window.focus();
}
}
Det jag menar är att du använder något liknande detta.
OM man läser väldigt noga mellan raderna skönjer man att jag menar "vi kommer in på en javascript-fråga". Det hade underlättat för er om jag skrivit det också! :r
Det går att följa länken i de webbläsare som kan följa länkar, däremot öppnas länken i ett nytt fönster bara i de webbläsare som även förstår skriptet. Om jag inte minns fel har äldre versioner av Safari en bugg där e.target kan retunera ett textNode (istället för en elementNode), samt IE6 behöver ett aningen modifierat skript med attachEvent och e.srcElement eller så.
if (document.addEventListener) {
document.addEventListener("click", pop, false);
} else if (document.attachEvent) { //msie
document.attachEvent("onclick", pop);
}
function pop(e) {
var elm;
if (e.target) {
elm = e.target;
} else if (e.srcElement) { //msie
elm = e.srcElement;
}
while (elm.nodeName != "A") {
elm = elm.parentNode;
}
if (elm.className == "pop" && elm.href) {
return !window.open(elm.href);
}
return true;
}
139 ms totalt · 3 externa anrop · v20260731065814-full.25f56b17