Wenn man ein Plugin beispielsweise für jQuery entwickelt, welches die Oberfläche einer Webanwendung modifiziert, wie beispielsweise jQuery.FancySelect, dann sieht man häufig, dass Entwickler mit IDs arbeiten. Das ist prinzipiell auch nicht schlecht, da die ID-basierte Selektor-Performance in JavaScript und CSS immer noch die beste ist.
Aber auch heute noch, wo man mit Javascript-Frameworks wie Ext.JS ganze Anwendungen erstellt, gibt es Entwickler, die ihre selbst ins DOM eingefügten Elemente mit fixen IDs versehen. IDs, die im Quelltext ihres Plugins zu 100% fest definiert sind.
Aus bestimmten Gründen, habe ich im Plugin jQuery.FancySelect auch IDs verwendet Allerdings sind die dynamisch generiert und werden dabei mit einem Prefix zusätzlich zur ID des ursprünglichen Select-Feldes generiert. Damit ist man nicht 100%ig sicher, aber 99% sind für den Fall genug.
Allerdings bin ich neulich über den Fall gestolpert, dass ein Entwickler(-Team) eine Erweiterung für eine Software, deren Frontend zu 100% auf Ext.JS basiert geschrieben hat. Diese Erweiterung bietet auch Dropdowns an, die durch Ext erzeugt wurden. Zusätzlich geben die Entwickler den Dropdowns noch fixe IDs, um die Dropdowns in ihrem Programmcode dynamisch anzuzeigen und deren Inhalte zu steuern.
[red_box]
ID ist englisch und bedeutet “Identifier“. In einem Dokument sollte eine ID damit nur einmal vorkommen, sonst ist sie ja nicht mehr identifizierend für ein einzelnes Element. Will man CSS oder JavaScript auf mehrere Elemente anwenden, sollte man das class-Attribut anstelle von id verwenden.
[/red_box]
Die Dropdowns werden damit in einem “multiplizierbaren” Reiter angezeigt, so dass diese Dopdowns durchaus häufiger im DOM vorkommen können. Und Ext blendet unsichtbare bzw. inaktive Tabs nur aus, entfernt Sie aber nicht aus dem DOM. Und die haben dann am Ende alle die gleichen IDs. Das führt unweigerlich zu Problemen, wenn z.B. jQuery( '#erstesdropdown' ); ausgeführt wird, um das eine Element mit der ID #erstesdropdown auszuwählen. In dem Fall, der mir über den Weg gelaufen ist, wurden in dem neuen duplizierten Tab einfach die Felder nicht mehr angezeigt. Wechselte man in den “originalen” Tab der Anwendung, waren auch hier die Felder “kaputt”.
Durch das Wesen der Anwendung war bei Erstellung des Plugins ürigens durchaus absehbar, dass der Fall vorkommen wird, dass zwei Tabs mit den durch das Plugin erweiterten Feldern geöffnet würden, der Konflikt hier war also im wahrsten Sinne “vorprogrammiert”.
Was nehmen wir also mit: Genreriert IDs dynamisch oder nutzt erst gar keine. Immerhin gibt es in jQuery und auch in Ext mit der Sizzle-Engine durchaus kontextbezogen nutzbare Selektoren, die Dinge wie “Geh’ solange im DOM-Baum hoch, bis du im Formular bist und suche dann alle untergeordneten Felder mit der Klasse ‘erweitertesFeld'” verstehen. Das mag stellenweise etwas komplexer und langsamer sein, aber wenn man das etwas optimiert, geht das.
Das bedeutet zwar, dass die initiale Erstellung (in diesem Fall wirklich nur sehr geringfügig) aufwändiger gewesen wäre, dafür aber nach hinten hinaus weniger Probleme und Inkompatibilitäten verursacht hätte.