Tipp-Sammlung

[Kai345]

Grütze .. äh ... Grüße!

Ich schon wieder ;)

In diversen Blogs und Seiten findet man immer mal wieder mehr oder weniger nützliche Tricks, z.B. das hier ist süß:

Ist es ein IE?
var ie = /*@cc_on!@*/false;

Oder IE-Version ermitteln:
var jsVer/*@cc_on=@_jscript_version@*/; /* IE5.01: 5.1 IE 5.5: 5.5 IE6: 5.6 IE7: 5.7 */

(beides gefunden bzw inspiriert von http://dean.edwards.name/)

Gibt es eigentlich Seiten, die sich auf das Sammeln solcher Tricks und Tipps spezialisiert haben, es ist ja unmöglich alle Seiten und Blogs dauerhaft zu lesen (hey, ich komme manchmal schon alleine bei diesem Forum nicht nach) bzw ist für Selfthml sowas angedacht?

Cü
Kai

[Micha]

Hallo Kai345,

Gibt es eigentlich Seiten, die sich auf das Sammeln solcher Tricks und Tipps spezialisiert haben

Sicher gibt es die, nur ist wohl deren Sinn fragwürdig. In JavaScript ist es meist uninteressant, welcher Browser vom User genutzt wird. Viel mehr sind dessen Eigenschaften bzw. die Kenntnis von Objekten und Methoden zu erfragen und entsprechend zu handeln.
Sicher gibt es den einen oder anderen Trick aber gerade Deine beiden gezeigten Beispiele finde ich weniger gelungen.

Mit freundlichem Gruß
Micha

[Kai345]

Grütze .. äh ... Grüße!

Sicher gibt es die, nur ist wohl deren Sinn fragwürdig. In JavaScript ist es meist uninteressant, welcher Browser vom User genutzt wird.

Es läßt sich aber leider nicht immer vermeiden, z.B. wenn eine bestimmte Funktion/Anweisung innerhalb einer Funktion explizit nur/außer im IE ausgeführt werden soll.

Außerdem meinte ich die Sammlung eher generell, für alles was mit JS zusammenhängt.

Cü
Kai

[Alexander (HH)]

Moin Moin!

Es läßt sich aber leider nicht immer vermeiden, z.B. wenn eine bestimmte Funktion/Anweisung innerhalb einer Funktion explizit nur/außer im IE ausgeführt werden soll.

Wann würde so etwas sinnvoll sein?

Außer um IE-Nutzern gezielt irgendwelche Malware durch eines der vielen IE-Löcher unterzuschieben oder IE-Usern den Zugang gezielt zu verweigern/erlauben sehe ich im Moment dafür keine praktische Anwendung, die nicht besser über eine Feature-Abfrage statt eine Browser-Abfrage realisiert würde.

Alexander

[plan_B]

Hallo,

Wann würde so etwas sinnvoll sein?

denke ein Kandidat ist createElement()

  
function create_input(name,typ)  
{  
// http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/createelement.asp  
// conditional compilation  
// http://msdn2.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx  
  
/*@cc_on @*/  
/*@if (@_jscript)  
  var ele=document.createElement('<input name="'+name+'" type="'+typ+'">');  
  @else @*/  
  var ele=document.createElement('input');  
  ele.name=name;  
  ele.type=typ;  
/*@end @*/  
return ele;  
}  

bin mir sicher, dass dieses Problem gestern fehlverhalten vom ie bzgl. selektieren von radio's die Ursache im createElement() hatte.

Gruß plan_B

[Micha]

Hallo plan_B,

denke ein Kandidat ist createElement()

Der sich mit einem einfach try-catch oder conditional comments umgehen lässt, wo ist da das Problem oder besser die Notwendigkeit?

Mit freundlichem Gruß
Micha

[plan_B]

Hallo,

denke ein Kandidat ist createElement()
Der sich mit einem einfach try-catch oder conditional comments umgehen lässt, wo ist da das Problem oder besser die Notwendigkeit?

wenn du hier liest http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/createelement.asp

beachte welche Einschränkungen es bezüglich name und type Attribut gibt.

das hat dann zur Folge das die input-Collection über den Namen beim IE nicht funktioniert, wie in dem Fall gestern.

var rbs=form.elements["radiobutton_name"];

alert(rbs.length)  // ergibt 0 bzw undefined

Der sich mit einem einfach try-catch ...

da sehe ich nicht, wie ein try catch weiterhilft. Läuft das nicht auf solche Verrenkungen raus, wie sie z.B. in dem oben verlinkten Thread gemacht wurden.

ich hoffe, habe dich jetzt nicht missverstanden?

Gruß plan_B

[Micha]

Hallo plan_B,

da sehe ich nicht, wie ein try catch weiterhilft.

ich dachte da an dieses Konstrukt, welches ich in meinem Tetris JavaScript verbaut habe:

  
try {  
 var inp = document.createElement("input");  
 inp.type = "checkbox";  
}  
catch(err) {  
 var inp = document.createElement('<input type="checkbox">');  
}

Läuft das nicht auf solche Verrenkungen raus

Jetzt, wo Du den Code siehst, darfst Du das selbst beantworten ;-)

ich hoffe, habe dich jetzt nicht missverstanden?

Sollte es so sein, hoffe ich, das es nun nicht mehr so ist ;-)

Gute Nacht
Micha

[Struppi]

try {
var inp = document.createElement("input");
inp.type = "checkbox";
}
catch(err) {
var inp = document.createElement('<input type="checkbox">');
}

  
Das musst du aber wenn umgekehrt einbauen, da der catch Block im Prinzip von keinem Browser ausgeführt wird, entweder er kann createElement oder kein try catch  
  

> > Läuft das nicht auf solche Verrenkungen raus  
> Jetzt, wo Du den Code siehst, darfst Du das selbst beantworten ;-)  
  
Die Frage ist, was ist schöner, einen Fehler erzeugen oder ein etwas seltsames Konstrukt im Code? Ich denke das läuft auf's selbe raus.  
  
Struppi.

[Micha]

Hallo Struppi,

Das musst du aber wenn umgekehrt einbauen, [...] entweder er kann createElement oder kein try catch

Nein. Das Einhängen bzw. Überschreiben des Type-Attributs führt im IE zum Fehler, der daraufhin in den catch-Block geht. Wenn es so nicht gehen würde, dürfte mein Tetris nicht laufen. Es müsste also reichen, wenn man es wie folgt formuliert:

  
//das koennen alle neuen Browser  
var inp = document.createElement("input");  
try {  
  // das nur die, die den Readonly-Status verletzen  
  inp.type = "checkbox";  
}  
catch(err) {  
  // der IE  
  inp = document.createElement('<input type="checkbox">');  
}

Ich denke das läuft auf's selbe raus.

"seltsame Konstrukt" könnte mit einem Update weg sein und man müsste sich wieder was neues einfallen lassen. Ich denke, try-catch wird der Browser in jedem Fall unterstützen. Drum denke ich nicht, das es auf selbe rausläuft. Ich füge nach ähnlichem Prinzip auch die style-Eigenschaft pointer hinzu. Ältere IEs lass ich im catch-Block laufen und weise hand zu.

Mit freundlichem Gruß
Micha

[Struppi]

Das musst du aber wenn umgekehrt einbauen, [...] entweder er kann createElement oder kein try catch

Nein. Das Einhängen bzw. Überschreiben des Type-Attributs führt im IE zum Fehler, ...

Das stimm nicht, du kannst bei einem neuen Element soviel den type überschreiben wie du möchtest auch im IE, du kannst ihn aber nicht bei einem bereits bestehenden ändern.

Struppi.

[Micha]

Hallo Struppi,

Vielen Dank für die Info!

Das stimm nicht, du kannst bei einem neuen Element soviel den type überschreiben wie du möchtest auch im IE

Ja, habe ich auch gerade bemerkt.

Mit freundlichem Gruß
Micha

[Don P]

Hallo Micha,

Ich weiß, dass ihr das konkrete Beispiel inzwischen als nicht ganz richtig entlarvt habt. Aber trotzdem mal prinzipiell die Frage, warum sollte man es so machen:

[...] führt im IE zum Fehler, der daraufhin in den catch-Block geht.

//das koennen alle neuen Browser
var inp = document.createElement("input");
try {
  // das nur die, die den Readonly-Status verletzen
  inp.type = "checkbox";
}
catch(err) {
  // der IE
  inp = document.createElement('<input type="checkbox">');
}

  
Die Variante im catch-Teil würde doch sicher browserunabhängig funktionieren, oder nicht? Warum dann überhaupt ein try-catch bemühen? Das bläht doch nur unnötig den Code auf.  
  
Ich versuche immer, so zu programmieren, dass möglichst alle den Code ausführen können, und mache solche try-catch-Kapriolen z.B. für versch. Browser nur, wenn unbedingt nötig.  
  
Gruß, Don P

[Struppi]

Die Variante im catch-Teil würde doch sicher browserunabhängig funktionieren, oder nicht?

Nein, tut sie nicht.

Struppi.

[Don P]

Hallo,

Die Variante im catch-Teil würde doch sicher browserunabhängig funktionieren, oder nicht?

Nein, tut sie nicht.

Oh, danke für die ausführliche Erklärung ;-).
Werde in Zukunft wohl präziser fragen müssen: ...und wenn nicht, um welche Browser handelt sich dabei?

Gruß, Don P

[Micha]

Hallo Don P,

um welche Browser handelt sich dabei?

Du hast den Kommentar im Script - explizit den im catch-Block - gelesen?

Mit freundlichem Gruß
Micha

[Don P]

Hallo Micha,

um welche Browser handelt sich dabei?
Du hast den Kommentar im Script - explizit den im catch-Block - gelesen?

Ja, hab ich natürlich. Alle anderen verstehen die Anweisung im catch-Block also definitiv nicht, ist klar – jetzt endlich. Dann will das erst mal so glauben.

Muss zugeben, dass ich noch nie einen anderen Browser als IE oder FF auf dem Schirm hatte und immer nur die wenige Funktionalität einsetze, die in SELFHTML als für alle gültig angegeben ist.

Btw, da SELFHTML ja vorbildlich immer angibt, welche Browserversion welche Funktionalität bzw. Syntax unterstützt, müsste es doch relativ einfach sein herauszufiltern, was z.B. alle können, oder auch, was ein bestimmter Browser nicht kann oder welche Spezialsyntax einer für eine gewisse Funktion braucht.
Vermutlich gibt es eine Datenbank, mit deren Hilfe man über eine geeignete Abfrage an so eine Liste herankommen könnte. Vielleicht sollte ich mal einen Thread dazu eröffnen oder ein Ticket anlegen (wie immer das gehen mag).

Gruß, Don P

[Struppi]

Hallo,

Die Variante im catch-Teil würde doch sicher browserunabhängig funktionieren, oder nicht?

Nein, tut sie nicht.

Oh, danke für die ausführliche Erklärung ;-).
Werde in Zukunft wohl präziser fragen müssen: ...und wenn nicht, um welche Browser handelt sich dabei?

Ich weiß nur vom IE dass der die Variante im catch Block kann, FF definitiv nicht, zum ausprobieren fehlt mir jetzt die Zeit.

Struppi.

[plan_B]

moin Micha,

wie Struppi schon schreibst, hast du dich da vertan. Deine catch greift nicht, weil der IE glatt durchläuft.

deine anderes Konstrukt gefällt mir da schon besser  :)

  
try { elem.style.cursor = "pointer"; } catch(e){ elem.style.cursor = "hand"; }  

mit diesem Schnipsel will ich zeigen, dass man nur Probleme hat, wenn man auf die HTMLCollection zugreift. Auf name und type jedes einzelen Elements hat man Zugriff.
Ich teste mit einem 6-IE, möglich das ältere sich anders verhalten haben

  
<input type="button" value="test IE createElement" onclick="test_ie(this)">  
  
function test_ie(button) {  
  
  function ausgabe(elem,txt) {  
  alert(txt  
   +"\n\t.name: "+elem.name  
   +"\n\t.type: "+elem.type  
   +"\n\t.value: "+elem.value ); }  
  
 var form=button.form;  
 var cb_name="cbx";  
 for (var i=0;i<3;i++) {  
  var ip=document.createElement("input");  
  try {  
   ip.name=cb_name;  
   ip.type="checkbox";  
   ip.value=i;  
   form.appendChild(ip);  
  }  
  catch(e) {  
   alert("Fehler beim Attribut setzen ");  
  }  
  ausgabe(ip, "nach createElement: ip")  
 }  
  
 var cbs=form.elements[cb_name];  
 try {  
  for (var ie=cbs.length,i=0; i<ie;i++) {  
   ausgabe( cbs[i],  
   "HTMLColloection "+i+". Element");  
  }  
 }  
 catch(e) {  
  alert("cbs: "+ cbs+"\t"+typeof(cbs)+  
   "\n\nhier liefert der IE keine HTMLCollection");  
 }  
 var z=form.elements.length;  
 for (var i=z-3;i<z;i++) {  
  ausgabe( form.elements[i],  
   "Elementnamen kann man doch abfragen?\nelements["+i+"]")  
  }  
 }  

Gruß plan_B

[Micha]

Hallo plan_B,

wie Struppi schon schreibst, hast du dich da vertan. Deine catch greift nicht, weil der IE glatt durchläuft.

Mein IE7 kann nun sogar das (oder konnte er das schon immer?):

  
window.onload = function() {  
 var doc = document.getElementsByTagName("body")[0];  
 var el = document.createElement("input");  
 el.type = "checkbox";  
 doc.appendChild(el);  
}

Da ich aber exakt dieses Problem schon hatte und es via tray-catch letztlich wie beschrieben gelöst habe, muss es ja mal sinnvollgewesen sein, sonst hätte ich meine Klappe gar nicht aufgemacht ;-)

Ich gebe mich aber erstmal geschlagen, angesichts der Übermacht :-)

deine anderes Konstrukt gefällt mir da schon besser

Das lindert den Schmerz ;-)

Mit freundlichem Gruß
Micha

[Cybaer]

Hi,

deine anderes Konstrukt gefällt mir da schon besser  :)

try { elem.style.cursor = "pointer"; } catch(e){ elem.style.cursor = "hand"; }

  
Da braucht's weder try-catch, noch CC: obj.cursor="hand"; if(obj.cursor!="hand") cursor="pointer";  
  
Unbekannte Styles sind, laut CSS-Spezifikation, vom Browser zu ignorieren. Da der (alte) IEs beim unbekannten "pointer" aber einen JS-Fehler meldet, macht man's halt andersrum. Denn andere Browser halten sich an die Spezifikationen ... >;->  
  
  
Gruß, Cybaer  

-- 
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!

[Cybaer]

Hi,

denke ein Kandidat ist createElement()
Der sich mit einem einfach try-catch oder conditional comments umgehen lässt, wo ist da das Problem oder besser die Notwendigkeit?

Mal abgesehen vom Umstand, daß es sicher nicht verkehrt ist, try-catch zu vermeiden, wo immer es geht (1. weil es IMHO prinzipiell nicht schön ist, Browser in Fehler zu jagen, um diese dann abzufangen, und 2. solcher Code schlicht langsamer ist): Wow! Conditional Compilation vermeiden, indem man Conditional Comments benutzt. Auf diese grandiose Idee muß man erstmal kommen. Klingt für mich eher nach "vom Regen in die Traufe"  ... =:->

Davon abgesehen gibt es so einige Fälle, wo es zwingend ist, explizit den IE vom Rest der Welt zu unterscheiden, weil eine Abfrage auf die IE-Objekte bzw. -Eigenschaften um die es geht, nicht möglich ist, weil andere Browser sie auch kennen - nur dummerweise anders behandeln (beispielsweise outerHTML oder bei den styleSheets die rules).

Ist halt alles eine Frage des "habe ich das schonmal gebraucht, oder theoretisier ich nur?". :-/

Gruß, Cybaer

PS: IMHO sollte man bei CC auch immer auf @_jscript abfragen, falls mal ein Browserhersteller auf die Idee kommen sollte, CC ebenfalls zu implementieren.

[Kai345]

Grütze .. äh ... Grüße!

Außer um IE-Nutzern gezielt irgendwelche Malware durch eines der vielen IE-Löcher unterzuschieben oder IE-Usern den Zugang gezielt zu verweigern/erlauben sehe ich im Moment dafür keine praktische Anwendung, die nicht besser über eine Feature-Abfrage statt eine Browser-Abfrage realisiert würde.

Ich habe zu einem Quiz, das ich geschrieben (na ja, zur Zeit eher noch zusammengehackt)
habe, Hilfe zu bestimmten Bedienelementen als CSS-divs angelegt. Leider hat der IE die sehr unschöne Angewohnheit, Formularelemente immer "on top" zu legen, wodurch das div mit dem Text zerstört wird. Also muß ich nur für IE einen iframe erzeugen, diesen durchsichtig machen und über die Formularelemente legen, bevor ich das div darauf positioniere. Welche Feature-Abfrage soll ich da nehmen? Frage ich dazu irgendeine Eigenschaft ab, die nur IE kennt, ist es genauso Browsersniffing wie es
var ie = /*@cc_on!@*/false; auch wäre.

Cü
Kai

[Alexander (HH)]

Moin Moin!

Leider hat der IE die sehr unschöne Angewohnheit, Formularelemente immer "on top" zu legen, wodurch das div mit dem Text zerstört wird. Also muß ich nur für IE einen iframe erzeugen, diesen durchsichtig machen und über die Formularelemente legen, bevor ich das div darauf positioniere. Welche Feature-Abfrage soll ich da nehmen? Frage ich dazu irgendeine Eigenschaft ab, die nur IE kennt, ist es genauso Browsersniffing wie es
var ie = /*@cc_on!@*/false; auch wäre.

Zugegeben, an diese spezielle Macke habe ich nicht gedacht. Macht aber nichts, hier kann man nicht-IEs die ganze Arbeit sehr leicht ersparen, indem man die ganze IFRAME-Kontruktion in IE Conditional Comments packt, so dass nicht-IEs den Workaround gar nicht erst sehen:

  
function ieInputFix(...)  
{  
    /*@cc_on  
    var iframe=....;  
    ....  
    @*/  
}  

und später:

  
function onLoadHandler()  
{  
    ....  
    ieInputFix(a,b,c);  
    ....  
}  

HTML-CCs wären auch denkbar, erzeugen aber u.U. invalides HTML und funktionieren erst ab IE 5.0.

Alexander

[Jonathan]

Hallo Alexander,

HTML-CCs wären auch denkbar, erzeugen aber u.U. invalides HTML

Kann ich nicht nachvollziehen.

und funktionieren erst ab IE 5.0.

Wer benutzt denn noch IE4? IE5 halte ich schon für kaum noch relevant.

Jonathan

[Alexander (HH)]

Moin Moin!

Hallo Alexander,

HTML-CCs wären auch denkbar, erzeugen aber u.U. invalides HTML

Kann ich nicht nachvollziehen.

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">  
<html>  
<head>  
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">  
<title>HTML-CC-Test</title>  
</head>  
<body>  
<p>  
<!--[if true]>IE<![endif]-->  
<![if false]>Nicht IE<![endif]>  
</p>  
</body>  
</html>  

Die erste CC-Zeile ist ein stinknormaler HTML-Kommentar, für den der IE eine Sonderbehandlung macht. Der zweiten CC-Zeile fehlen die Minus-Zeichen für einen Kommentar, was der Validator in seiner unnachahmlichen Art mit '"IF" is not a reserved name. "ENDIF" is not a reserved name.' kommentiert.

und funktionieren erst ab IE 5.0.

Wer benutzt denn noch IE4?

Jeder, der ein altes Windows hat und nicht auf den IE 5 oder neuer Updaten kann oder will.

IE5 halte ich schon für kaum noch relevant.

Na und? Das ändert nichts daran, dass der IE 4 und älter mit HTML-CCs nichts anfangen kann.

Alexander

[Jonathan]

Hallo Alexander,

Die erste CC-Zeile ist ein stinknormaler HTML-Kommentar, für den der IE eine Sonderbehandlung macht. Der zweiten CC-Zeile fehlen die Minus-Zeichen für einen Kommentar, was der Validator in seiner unnachahmlichen Art mit '"IF" is not a reserved name. "ENDIF" is not a reserved name.' kommentiert.

Das zweite ist ja auch kein Conditional Comment, weil kein Comment.

Nimm besser sowas:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">  
<html>  
<head>  
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">  
<title>HTML-CC-Test</title>  
</head>  
<body>  
<p>  
<!--[if true]>IE<![endif]-->  
<!--[if false]>-->Nicht IE<!--<![endif]-->  
<br>  
<!--[if IE 7]><!--> IE7 oder kein IE<!--<![endif]-->  
</p>  
</body>  
</html>

Jonathan

[Vinzenz Mai]

Hallo Kai,

ist für Selfthml sowas angedacht?

es gab mal einen Bereich "Tipps und Tricks", dieser ist inzwischen in den Bereich  SELFHTML-Artikel integriert worden. Wenn Du z.B. einen Artikel zu solchen Tipps und Tricks schreibst, dann ist Dir sicher niemand böse - und durch Reaktionen auf Deinen Artikel aktualisiert sich dieser möglicherweise fast von selbst.

Freundliche Grüße

Vinzenz