Frage zum Wiki-Artikel „data-*“

[Das Camel-Case]

FYI(?):

Zu „Mit Bindestrich zusammengesetzte data-Attribute werden in JavaScript zu camelCase.“

Dies (und vmtl. alle anderen Umgestaltungen, die z.B. MDN erwähnt) geschieht auch beispielsweise mit

document					// mostly you shouldn’t do this … says
.getElementsByTagName('p')	// https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/will-change
.forEach(x => x.style.willChange = 'contents');

was zu lauter
<p style="will-change: contents">

führt.

Interessant wäre womöglich, wo derartiges noch geschieht.

---

(Mehr oder weniger) lustig: man kann so direkte Zuweisungen von Style-Attributen vornehmen. Aber um sie wieder los zu werden, darf man dann doch wieder in die removeAttribute-Kiste greifen.

[Rolf B]

Hallo camelCase,

das ist bekannt und auch von uns beschrieben.

Das ist eine Eigenheit des CSSStyleDeclaration-Objekts, das dem stype-Property und der window.getComputedStyle() Funktion hinterlegt ist.

Ob dieses Mapping auch anderswo passiert, kann ich auswendig nicht sagen, aber wenn, dann ist es an Ort und Stelle beschrieben.

By the way:

Warning: Use the will-change property as a last resort to try to deal with existing performance problems. Don't use it to anticipate performance problems.

Rolf

[Felix Riesterer]

Liebe(r) Unbekannte(r),

Interessant wäre womöglich, wo derartiges noch geschieht.

warum sollte das interessant sein? Wenn Du Dinge tust, die zwar möglich sind, aber keinen echten Sinn haben, dann mag das für Dich einen gewissen Unterhaltungswert haben. Aber für echte Praktiker, die echte Probleme lösen müssen, ist das leider nur Quatsch.

Anstatt mit someNode.style.someStyle = "some value" zu hantieren, kannst Du someNode.classList.add("myClassName") oder someNode.classList.remove("myClassName") verwenden. Und wenn Du Data-Attribute verwendest, kannst Du Deine Selektoren so schreiben, dass sie auf passende Attribut-Werte reagieren:

<p data-irgend-was="das-eine">...</p>
<p data-irgend-was="">...</p>

const alleMitIrgendWas = document.querySelectorAll(
  "[data-irgend-was]"
);

alleMitIrgendWas.forEach(node => {
  // leere Attribut-Werte ignorieren
  if (node.dataset.irgendWas.length) {
    node.dataset.irgendWas = "das-andere";
  }
});

[data-irgend-was="das-eine"] { color: red; }
[data-irgend-was="das-andere"] { color: green; }

Aber um sie wieder los zu werden, darf man dann doch wieder in die removeAttribute-Kiste greifen.

Wenn Deine Selektoren einen leeren Attributwert nicht selektieren, ist das Vorhandensein des Data-Attributes kein Problem. Dann kannst Du es auch dort belassen.

Liebe Grüße

Felix Riesterer

[Das Camel-Case]

Warum das interessant sein könnte? Möglicherweise weil man in seinen Skripten evtl. Kollisionen zustande bringt. Immerhin ist so eine Namenskonvention ja etwas, das eher empfohlen wird und weniger ein Privileg.

Und weil so manches, gelegentlich im CSS (:is() usw.), vornehmlich aber in JS, „verziehen“ wird (ich sag’ da mal: Syntax-Fehler, die gelegentlich zur Laufzeit auftreten und deshalb u.U. selbst mit intensivem Austesten unbemerkt bleiben, womöglich in irgend einem try-catch-finaly verschwinden …), könnte man damit wunderliche Dinge erleben.

Ansonsten: die „shorthand-Zuweisung“ war mir da ja nur ein Provisorium. Damit ein Teil der Baustelle bearbeitet werden konnte, während das Provisorium „die Fenster offen hielt“. Ohne dieses hätte ich den anderen Teil „abstützen“ müssen. — Mittlerweile ist das, dank „freier Sicht“, schon wieder weg.

Aber: dabei ist mir eben aufgefallen, daß auch da und nicht nur bei den data-… die Bezeichner so umgetauft werden.

[Gunnar Bittersmann]

@@Das Camel-Case

Warum das interessant sein könnte? Möglicherweise weil man in seinen Skripten evtl. Kollisionen zustande bringt. Immerhin ist so eine Namenskonvention ja etwas, das eher empfohlen wird und weniger ein Privileg.

Und weil so manches, gelegentlich im CSS (:is() usw.), vornehmlich aber in JS, „verziehen“ wird (ich sag’ da mal: Syntax-Fehler, die gelegentlich zur Laufzeit auftreten und deshalb u.U. selbst mit intensivem Austesten unbemerkt bleiben, womöglich in irgend einem try-catch-finaly verschwinden …), könnte man damit wunderliche Dinge erleben.

?? (mir unverständliches Zeugs)

---

Aber: dabei ist mir eben aufgefallen, daß auch da und nicht nur bei den data-… die Bezeichner so umgetauft werden.

Wenn dir das nicht zusagt, kannst du statt

document.documentElement.style.backgroundColor = 'rebeccapurple';

ja

document.documentElement.style.setProperty('background-color', 'rebeccapurple');

verwenden. Bei custom properties (die mit -- anfangen) muss man das so tun.

Erwähnte ich schon, dass man CSS-Eigenschaften möglichst nicht direkt mit JavaScript setzen sollte?

(Ausgenommen custom properties, die ein Weg sein können, Daten in CSS verfügbar zu machen, bspw. die Uhrzeit.)

🖖 Live long and prosper

[Felix Riesterer]

Lieber Gunnar,

document.documentElement.style.setProperty('background-color', 'rebeccapurple');

verwenden. Bei custom properties (die mit -- anfangen) muss man das so tun.

gerade getestet:
document.body.style["--myVar"] = "myValue" leistet nicht dasselbe,
document.body.setAttribute("style","--myVar: myValue") dagegen schon.

Liebe Grüße

Felix Riesterer

[Das Camel-Case]

„Unverständliches Zeugs“ ist ja, so ungefähr, das (potentielle) Problem: wenn irgendwo (in obendrein unbekannter Weise) aus anscheinend unterschiedlichen Dingen (hier: Identifier) doch das gleiche wird, dabei dann aber ohne „laute“, möglichst früh bemerkbare, Auswirkungen irgendwie verwurstelt wird, können Dinge geschehen, die sich nur schwer vorstellen lassen.

Und wenn sie dann doch bemerkt werden ist danach die Ursache meist noch viel schwerer auffindbar.

Ich erinner mich in solchen Zusammenhängen an manch (mittlerweile „antikes“) Problem mit dem automatischen Konvertieren von Daten (ganz ähnlich wie in JS) in Excel. Auch wenn es selten vorkam: gelegentlich mußte ich Hilfszellen anlegen, die nur dafür gesorgt haben, daß z.B. aus einer Zahl keinesfalls ein Text gemacht wurde. Auch da war bei der Fehlersuche dieses „Spur zum …“ kaum eine Hilfe, denn die Tabellen war dabei typischerweise „etwas größer“ (> 20000 Zellen, die in vielfältiger Weise über die Formeln miteinander verbunden waren).

[Felix Riesterer]

Liebe(r) Unbekannte(r),

„Unverständliches Zeugs“ ist ja, so ungefähr, das (potentielle) Problem: wenn irgendwo (in obendrein unbekannter Weise) aus anscheinend unterschiedlichen Dingen (hier: Identifier) doch das gleiche wird, dabei dann aber ohne „laute“, möglichst früh bemerkbare, Auswirkungen irgendwie verwurstelt wird, können Dinge geschehen, die sich nur schwer vorstellen lassen.

was Du beschreibst hat einen Namen: garbage in, garbage out

Liebe Grüße

Felix Riesterer

[Das Camel-Case]

Und wer hat dann den Müll gemacht? Die Person, die da (eher unbedarft) einen CamelCase-Selektor (oder sonst etwas da passendes) gewählt hat? Und eben nicht davon gehört hat, daß ein anderer Selektor möglicherweise so „umgetauft“ wird?

[Felix Riesterer]

Liebe(r) Unbekannte(r),

Und wer hat dann den Müll gemacht?

diejenige, die die Standards der verwendeten Sprachen nicht genügend gut kennt. Nur weil Du es nicht gut findest, heißt das nicht, dass damit etwas falsch ist. Deswegen lehne ich Deine Kritik ja als Geschwurbel ab!

Und eben nicht davon gehört hat, daß ein anderer Selektor möglicherweise so „umgetauft“ wird?

Da haben wir's: Nicht genügend gut informiert/ausgebildet/erfahren etc. Das ist aber nicht der Fehler der verwendeten Technologien, sondern Deiner.

Liebe Grüße

Felix Riesterer

[Das Camel-Case]

Wenn ich jetzt aber überlege, wie oft in den letzten Monaten „irgendwo“ (hier, MDN, …) zu solchen Dingen gestöbert habe und dabei doch öfter mal über „das stand ‚gestern‘ aber noch nicht so da“ gestolpert bin …

Vielleicht sollte man also lieber nicht function …˚ oder for(…)˚ schreiben, denn wer weiß, ob das „morgen“ noch irgend einem Standar…¿d? entspricht?

Oder, anders herum: JS ist eine Wegwerf-Sprache, es lohnt nicht, sich Codebibliotheken anzulegen, die ja „demnächst“ aus lauter fehlerhaften Interpretationen unbekannter Art bestehen (könnten)?

[Gunnar Bittersmann]

@@Das Camel-Case

Zu „Mit Bindestrich zusammengesetzte data-Attribute werden in JavaScript zu camelCase.“

Ja, weil das Zeichen - (U+002D) in JavaScipt die Bedeutung „Minuszeichen“ hat und deshalb nicht als Bindestrich verwendet werden kann.

Interessant wäre womöglich, wo derartiges noch geschieht.

Auch bei ARIA, bspw. Element.ariaExpanded.

Und BTW: In HTML heißt das Attribut zwar nicht tab-index, sondern tabindex; in JavaScript heißt’s aber HTMLElement.tabIndex.

---

(Mehr oder weniger) lustig: man kann so direkte Zuweisungen von Style-Attributen vornehmen.

Dass man das zwar kann, aber möglichst nicht tun sollte, hat @Felix Riesterer ja schon angedeutet.

Aber um sie wieder los zu werden, darf man dann doch wieder in die removeAttribute-Kiste greifen.

Huch, da war ich selbst überrascht, dass das geht:

document.documentElement.style.backgroundColor = 'rebeccapurple';
document.documentElement.removeAttribute('style');

Du musst aber nicht in die removeAttribute-Kiste greifen. Zum Zurücksetzen geht

document.documentElement.style.backgroundColor = '';

oder

document.documentElement.style.backgroundColor = 'revert';

bzw.

document.documentElement.style.backgroundColor = 'unset';

🖖 Live long and prosper

[Felix Riesterer]

Lieber Gunnar,

Huch, da war ich selbst überrascht, dass das geht:

document.documentElement.style.backgroundColor = 'rebeccapurple';
document.documentElement.removeAttribute('style');

damit sind dann aber alle Zuweisungen an das style-Objekt weg. Etwa wie style.* = "" . Ob man das will? Sicher nur dann, wenn man ohnehin schon sehr konfus vorgeht.

Liebe Grüße

Felix Riesterer

[Das Camel-Case]

Dass man das zwar kann …

Worauf ich ja, vor allem für das, was im Beispiel verwendet wurde, auch hingewiesen hatte: “mostly you shouldn’t do this …”

… Zum Zurücksetzen geht = '' –

Ja. Mit einem „optischen Fehler“: es bleibt ein Eintrag im HTML-Code und „nur“ die Auswirkungen werden aufgehoben ('') oder zurückgenommen (revert). — Was für mich bedetet, daß es (so möglich) „richtig weggemacht“ wird. (Dieses Mal: die „Baustütze“ wird nach dem erfolten „Trockenbau“ einfach nicht mehr eingebaut.)

(Nebenbemerkung: zumindest ein Aha-Effekt ausgelöst, das ist mir gut fürs Karma! SCNR)

weil das Zeichen - (U+002D) in JavaScipt die Bedeutung „Minuszeichen“ hat …

Es ist immerhin bekannt (was einer möglichen Fehlersuche ja nicht abträglich ist). Und: ganz so einfach ist es ja auch wieder nicht: ist es ein Minus, ist es ein Vorzeichen … oder einfach ein Teil eines Identifieres? Womöglich gar der Anfang eines benutzerdefinierten? …