Webseiten Hintergrundfarbe um x Uhr ändern

[jaku]

Hallo,

kurz zum Hintergrund, mittels einem Raspberry und Funksteckdosen kann ich über eine lokale Webseite Steckdosen bzw. Lampen schalten.

Auf dem Raspberry läuft ein installierter lighttpd Web-Server.

Die Webseite ist auf einem Tablet permanent geöffnet.

Mein Vorhaben, ich möchte die Hintergrundfarbe auf dieser geöffneten Webseite zu einer bestimmten Uhrzeit ändern ohne die Webseite händisch neu zu laden.

Wer hat eine Idee wie man dies umsetzten könnte?

Für Anregungen und oder Stichworte wäre ich dankbar.

Beste Grüße Jan

[Matthias Apsel]

Hallo jaku,

Wer hat eine Idee wie man dies umsetzten könnte?

Für Anregungen und oder Stichworte wäre ich dankbar.

• JavaScript
• setTimeout
• Klassennamen des HTML-Elements ändern
• CSS:
  • Einbindung
  • Klassenselektor
  • background-color

Bis demnächst
Matthias

[Der Martin]

Hi,

Auf dem Raspberry läuft ein installierter lighttpd Web-Server.

Die Webseite ist auf einem Tablet permanent geöffnet.

Mein Vorhaben, ich möchte die Hintergrundfarbe auf dieser geöffneten Webseite zu einer bestimmten Uhrzeit ändern ohne die Webseite händisch neu zu laden.

Wer hat eine Idee wie man dies umsetzten könnte?

du sagst, das soll clientseitig ablaufen, ohne Reload. Dann kommt also nur Javascript in Frage.

Für Anregungen und oder Stichworte wäre ich dankbar.

Frage in einem bestimmten Zeitraster (10s ist vermutlich ausreichend genau) die aktuelle Uhrzeit ab, und sobald der vorgegebene Zeitpunkt überschritten ist, ändere eine Klasse des body- oder html-Elements, so dass CSS mit einer Änderung der Hintergrundfarbe darauf reagieren kann.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Frage in einem bestimmten Zeitraster (10s ist vermutlich ausreichend genau) die aktuelle Uhrzeit ab,

Das muss man doch gar nicht ständig tun. Nach der initialen Abfrage der aktuellen Urzeit weiß man doch die Differenz zur Zielzeit und kann einen Timer entsprechend starten.

Bei Bedenken hinsichtlich Genauigkeit kann man den Timer auch etwas vorher ablaufen lassen, die aktuelle Urzeit abfragen und einen weiteren Timer setzen …

LLAP 🖖

[Der Martin]

Moin,

Frage in einem bestimmten Zeitraster (10s ist vermutlich ausreichend genau) die aktuelle Uhrzeit ab,

Das muss man doch gar nicht ständig tun. Nach der initialen Abfrage der aktuellen Urzeit weiß man doch die Differenz zur Zielzeit und kann einen Timer entsprechend starten.

daran dachte ich zunächst auch, aber ...

Bei Bedenken hinsichtlich Genauigkeit

... dieser Aspekt ließ mich davon Abstand nehmen.

kann man den Timer auch etwas vorher ablaufen lassen, die aktuelle Urzeit abfragen und einen weiteren Timer setzen …

Das ist natürlich auch eine Möglichkeit!

So long,
 Martin

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Nach der initialen Abfrage der aktuellen Urzeit

Wie kann denn die Urzeit aktuell sein‽

Hab ich hier wirklich „Urzeit“ geschrieben?

die aktuelle Urzeit abfragen und einen weiteren Timer setzen …

Sieht so aus.

Das ist mir jetzt zu blöd; das lass ich so stehen.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Das muss man doch gar nicht ständig tun. Nach der initialen Abfrage der aktuellen Urzeit weiß man doch die Differenz zur Zielzeit und kann einen Timer entsprechend starten.

Das ist zwar prinzipiell richtig, aber gibt potentiell Probleme bei so fiesen Sachen wie Sleep/Standby. Keine Ahnung, wie genau das bei Android aussieht, aber bei iOS stoppt der Browser wenn das Tablet schlafen geht (bzw das Display ausschaltet).

Ein Interval, dass regelmäßig prüft, ist hier die robustere Variante.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Das ist zwar prinzipiell richtig, aber gibt potentiell Probleme bei so fiesen Sachen wie Sleep/Standby.

Hm …

Keine Ahnung, wie genau das bei Android aussieht, aber bei iOS stoppt der Browser wenn das Tablet schlafen geht (bzw das Display ausschaltet).

… gibt es denn kein Event, das gefeuert wird, wenn das Gerät aus dem Schalfmodus erwacht?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Keine Ahnung, wie genau das bei Android aussieht, aber bei iOS stoppt der Browser wenn das Tablet schlafen geht (bzw das Display ausschaltet).

… gibt es denn kein Event, das gefeuert wird, wenn das Gerät aus dem Schalfmodus erwacht?

Man könnte vielleicht auf das visibilitychange-Event horchen. Aber ein wirkliches Event gibt es dafür meines Wissens nach nicht.

LG,
CK

[Google weiß alles]

Für Anregungen und oder Stichworte wäre ich dankbar.

Javascript.

//Zeit:
var t = new Date();
var h = t.getHours();

//body als Objekt:
var body = document.getElementsByTagName('body')[0];

//Vergleich:
if (h > 6 && h < 22) {
   // …
} else {
   // …
}

// Objekt eine Hintergrundfarbe verpassen:
body.style.backgroundColor = '#ccf';  //schlüpferblau

//  Eine Funktion mit Namen nachtschalter in 60 Sekunden ausführen:
window.setTimeout(nachtschalter, 60000);
// Hint: Das kann genau in der Funktion, oft als letzte Zeile, stehen.

//  Eine Funktion mit Namen nachtschalter nach Laden des Dokumentes ausführen:
document.onload=nachtschalter();

[Reinhard]

Hey,

var body = document.getElementsByTagName('body')[0];

Hast du was an document.body auszusetzen?

//Vergleich:
if (h > 6 && h < 22) {
   // …
} else {
   // …
}

Ich vermute mal, das ist die Stelle, an der die Farbe umgeschaltet werden soll. Macht also wenig Sinn, das so umzusetzen. Eine Funktion wäre hier wohl angebracht, wie du hier bereits erwähnst:

document.onload=nachtschalter();

Aber bitte mit addEventListener() und – vor allem – ohne die Klammern, ich hatte erwartet, das sei dir bekannt.

window.setTimeout(nachtschalter, 60000);

Und so macht auch setTimeout() eher keinen Sinn, es wäre doch reichlich eigenartig, erneut ein immer gleiches Timeout in der Funktion selbst zu setzen. setInterval() ist dein Freund – wenn du es so machen willst. Möglicherweise wäre es eleganter zu berechnen, wieviel Zeit bis zur gewünschten Uhrzeit noch verbleibt, dann spräche auch nichts dagegen, setTimeout() innerhalb der Funktion wieder neu zu berechnen.

Reinhard

[Google weiß alles]

var body = document.getElementsByTagName('body')[0];

Hast du was an document.body auszusetzen?

Klar. Viel zu kurz!

Ich vermute mal, das ist die Stelle, an der die Farbe umgeschaltet werden soll. Macht also wenig Sinn, das so umzusetzen. Eine Funktion wäre hier wohl angebracht, wie du hier bereits erwähnst:

Es war nach Stichworten gefragt. Ich habe mit Absicht keine komplette Funktion gepostet. Wohl aber eine mitsamst der Webseite erstellt. Weil ich gerne Tippfehler mache die mir dann in der Konsole gezeigt werden.

document.onload=nachtschalter();

Aber bitte mit addEventListener() und – vor allem – ohne die Klammern, ich hatte erwartet, das sei dir bekannt.

Hab tatsächlich schon von dieser hässlichen Schreibweise gehört. Ist document.onload denn schon ausgelistet?

setInterval()

Dieses neumodische Zeug muss aber erstmal von meinem alzheimer_syndrom() gespeichert werden. Vielleicht habe ich ja mal etwas wie var now = new Date('lichter Moment').

Möglicherweise wäre es eleganter zu berechnen, wieviel Zeit bis zur gewünschten Uhrzeit noch verbleibt, dann spräche auch nichts dagegen, setTimeout() innerhalb der Funktion wieder neu zu berechnen.

Hm... naja ... was machst Du wenn das Skript wie beschrieben unbestimmte Zeit, also einen ganzen Tag, 4 Tage oder 2 Wochen laufen soll? "Elegant" alle Umschalttermine bis Sankt Nimmerlein vorberechnen? Erschien mir zu mühselig. Dachte mir, "Hach, schau einfach mal jede Minute nach, was die Uhr so anzeigt. Ist sowieso die nächste Frage."

[Camping_RIDER]

Aloha ;)

document.onload=nachtschalter();

Aber bitte mit addEventListener() und – vor allem – ohne die Klammern, ich hatte erwartet, das sei dir bekannt.

Hab tatsächlich schon von dieser hässlichen Schreibweise gehört. Ist document.onload denn schon ausgelistet?

Wie dir wahrscheinlich bekannt ist hat diese "hässliche Schreibweise" den sehr wichtigen Vorzug der Zukunftssicherheit, da die mittels addEventListener() registrierte Funktion auch dann aufgerufen wird, wenn ein weiteres Skript den onload-Platz für sich beansprucht - und das ganz ohne weitere, aufwändige Vorkehrungen durch den jeweiligen Programmierer. Die Verwendung von onload ist dementsprechend inzwischen so eindeutig bad practice, dass ich sie in Code, von dem jemand lernen soll, dringend vermeiden würde.

Für den TO noch ein Beispiel für gleichwertigen Code mittels addEventListener():

document.addEventListener("load",nachtschalter);

Grüße,

RIDER

[Orlok]

Hallo

body.style.backgroundColor = '#ccf';  //schlüpferblau

Da deswegen noch niemand gemeckert hat, mache ich das mal. ;-)

Styles mit JavaScript setzen ist nicht gerade vorbildlich, denn die Zuständigkeiten sollten sauber getrennt werden. Das heißt, die entsprechende Information gehört natürlich ins Stylesheet.

.fromDuskTillDawn {
  background-color: midnightblue;
}

In JavaScript wäre dann, wenn die Zeit gekommen ist, die Klasse hinzuzufügen.

document.body.classList.add('fromDuskTillDawn');

Viele Grüße,

Orlok

[Matthias Scharwies]

Servus!

Da deswegen noch niemand gemeckert hat, mache ich das mal. ;-)

document.body.classList.add('fromDuskTillDawn');

Regel: Klassennamen sollten nach Klassikern benannt werden!

+1

Herzliche Grüße

Matthias Scharwies

[Der Martin]

Hallo,

document.body.classList.add('fromDuskTillDawn');

Regel: Klassennamen sollten nach Klassikern benannt werden!

ja, dann aber auch bitte richtig mit großem Anfangsbuchstaben: FromDuskTillDawn.
Dieses Semi-CamelCase sieht für mich immer irgendwie kaputt aus. Woher kommt die blöde Angewohnheit, ausgerechnet den Anfangsbuchstaben entgegen der restlichen Konvention klein zu schreiben?

So long,
 Martin

[encoder]

Dieses Semi-CamelCase sieht für mich immer irgendwie kaputt aus. Woher kommt die blöde Angewohnheit, ausgerechnet den Anfangsbuchstaben entgegen der restlichen Konvention klein zu schreiben?

Vielleicht daher weil man "eigentlich" klein schreiben will, aber zwischendurch Großbuchstaben zur Optik einsetzt?

Ich habe mir eine Weile lang angewöhnt, bei case sensitiven Dingen die mir nicht sofort sagen was falsch ist möglichst alles komplett klein zu schreiben. Also PHP, Javascript und so weiter, was nicht compiliert wird und sofort ausdrücklich meckert sondern still und leise falsch läuft. Camel ist dann nur eine optische Hilfe.

[Robert B.]

Moin,

Dieses Semi-CamelCase sieht für mich immer irgendwie kaputt aus. Woher kommt die blöde Angewohnheit, ausgerechnet den Anfangsbuchstaben entgegen der restlichen Konvention klein zu schreiben?

Vielleicht zur Unterscheidung von Konstanten, die man gerne mit einem Großbuchstaben anfangen lässt.

Viele Grüße
Robert

[Camping_RIDER]

Aloha ;)

Dieses Semi-CamelCase sieht für mich immer irgendwie kaputt aus. Woher kommt die blöde Angewohnheit, ausgerechnet den Anfangsbuchstaben entgegen der restlichen Konvention klein zu schreiben?

Wie die anderen schon sagten - es ist (in JS) Konvention, dass Variablennamen (wie auch Funktionsbezeichner - in JS besteht da sowieso kein großer Unterschied) mit Kleinbuchstaben beginnen, während Konstanten und Klassen mit Großbuchstaben beginnen (wobei Konstanten im Gegensatz zu Klassen meist vollständig in Caps gehalten sind).

Die Schreibung des ersten Buchstabens ergibt sich also aus Konventionen - die Binnen-Caps sind zur Worttrennung da, und auch Gegenstand von Konventionen (z.B. in PHP sind die Konventionen was Worttrennung angeht traditionell ja anders - mit _). Das ist auch nicht nur in JS so, sondern auch in Java und einigen weiteren Sprachen, die ihre Syntax an C-Syntax anlehnen.

Dass man im CSS-Bereich auf die von JS bekannten Konventionen zurückgreift und instinktiv Bezeichner so wählt, wie man Variablenbezeichner in JS wählen würde, halte ich für plausibel und verständlich.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

z.B. in PHP sind die Konventionen was Worttrennung angeht traditionell ja anders - mit _

Ist das so? Bei den Funktionsbezeichnern geht’s in PHP drunter und drüber – mal mit mit _, mal mit CamelCase. Ich sehe da keine Tradition, nur ein heilloses Durcheinander.

Dass man im CSS-Bereich auf die von JS bekannten Konventionen zurückgreift und instinktiv Bezeichner so wählt, wie man Variablenbezeichner in JS wählen würde, halte ich für plausibel und verständlich.

Ich nicht. Vielmehr ist eine bekannte Konvention, dass was in CSS mit - geschrieben wird in JavaScript als CamelCase erscheint. (background-color wird bspw. zu backgroundColor.)

Da in CSS das - innerhalb von Zeichenketten nicht die Bedeutung eines Minuszeichens haben kann, steht - als Trennzeichen in Klassenbezeichnern und IDs zur Verfügung.

Aufgrund der besseren Lesbarkeit würde ich - in Bezeichnern gegenüber CamelCase vorziehen.

In JavaScript tauchen diese Bezeichner auch nur in ' (bzw. ") in Argumenten von Methoden wie querySelector() auf, - stellt da also kein Problem dar.

LLAP 🖖

PS: Kann man mal bitte wieder den Rahmen und die Hintergrundfarbe von in ` eingeschlossenen Zeichen wegmachen? Das sieht ja scheußlich aus und stört den Lesefluss.

[Camping_RIDER]

Aloha ;)

z.B. in PHP sind die Konventionen was Worttrennung angeht traditionell ja anders - mit _

Ist das so? Bei den Funktionsbezeichnern geht’s in PHP drunter und drüber – mal mit mit _, mal mit CamelCase. Ich sehe da keine Tradition, nur ein heilloses Durcheinander.

Traditionell meinte an der Stelle mehr "am Anfang wars so" als "es ist immer noch so" - Ja, PHP hat viele Schwächen, historisch gewachsene Altlasten, z.B. in der Benennung, ist eine davon.

Dass man im CSS-Bereich auf die von JS bekannten Konventionen zurückgreift und instinktiv Bezeichner so wählt, wie man Variablenbezeichner in JS wählen würde, halte ich für plausibel und verständlich.

Ich nicht. Vielmehr ist eine bekannte Konvention, dass was in CSS mit - geschrieben wird in JavaScript als CamelCase erscheint. (background-color wird bspw. zu backgroundColor.)

Da in CSS das - innerhalb von Zeichenketten nicht die Bedeutung eines Minuszeichens haben kann, steht - als Trennzeichen in Klassenbezeichnern und IDs zur Verfügung.

Vollkommen richtig; meine Behauptung war ja nicht, dass CamelCase Konvention in CSS ist, sondern nur, dass ich es verständlich finde, eine anderweitig bekannte Konvention instinktiv heranzuziehen. Abgesehen davon, dass ich jederzeit fromDuskTillDawn dem optisch weniger kompakten from-dusk-till-dawn vorziehen würde. Zumal der von dir genannte Vergleich ein wenig hinkt - das umsetzen von - in CamelCase betrifft ausschließlich CSS-Attribute - keine Selektoren u.ä... also ja, kann man so machen, aber eine Konvention bezüglich CSS in der Gesamtheit daraus abzuleiten halte ich für eine eher schwach untermauerte These.

Aufgrund der besseren Lesbarkeit würde ich - in Bezeichnern gegenüber CamelCase vorziehen.

Offensichtlich kollidieren hier zwei subjektive Prioritätenverteilungen. Mir wäre im Beispiel die Kompaktheit wichtiger als die Lesbarkeit. Darüber müssen wir sicher nicht im Einzelnen diskutieren, aber es ist ein Indiz dafür, dass die angeführte Konvention (zumindest meiner Wahrnehmung nach) nicht uneingeschränkt konsensfähig ist.

In JavaScript tauchen diese Bezeichner auch nur in ' (bzw. ") in Argumenten von Methoden wie querySelector() auf, - stellt da also kein Problem dar.

Selbstverständlich, deine Argumentation hinsichtlich der Möglichkeit - zu verwenden ist ja auch vollständig richtig.

PS: Kann man mal bitte wieder den Rahmen und die Hintergrundfarbe von in ` eingeschlossenen Zeichen wegmachen? Das sieht ja scheußlich aus und stört den Lesefluss.

Mir wäre es lieber, wenn du auf ein Ceterum censeo verzichten würdest. Ich halte das für eine unlautere Art, eine Meinung zu vertreten, da der einzige Zweck darin besteht, Druck zu erhöhen oder aufrechtzuerhalten - und das sollte in einer Gemeinschaft nicht das Mittel der Wahl sein, um einen Standpunkt zu vertreten. Es hinterlässt einen unangenehmen Beigeschmack.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Vollkommen richtig; meine Behauptung war ja nicht, dass CamelCase Konvention in CSS ist, sondern nur, dass ich es verständlich finde, eine anderweitig bekannte Konvention instinktiv heranzuziehen.

Da Klassen ein Konstrukt im Markup sind, schauen wir uns mal zuerst HTML an:

Da HTML (wenn nicht in XML-Syntax geschrieben) nicht case-sensitiv ist, ist die Frage nach CamelCase in HTML müßig. Man könnte tBody etc. schreiben; üblich ist das aber nicht. - hingegen ist in HTML durchaus üblich: bspw. bei data-*- und aria-*-Attributbezeichnern.

Auch CSS ist nicht case-sensitiv, was die Bezeichner der Eigenschaften angeht. Allerdings ist - dort weit verbreitet.

Was kümmern einen HTML/CSS-Entwickler Konventionen aus Programmiersprachen? Es sollten doch vielmehr Konventionen gelten, die HTML und CSS bereits eigen sind. Auch das spricht für die Verwendung von -, nicht CamelCase.

Abgesehen davon, dass ich jederzeit fromDuskTillDawn dem optisch weniger kompakten from-dusk-till-dawn vorziehen würde. […] Mir wäre im Beispiel die Kompaktheit wichtiger als die Lesbarkeit.

Mit dem Argument könntest du ja gleich fromdusktilldawn schreiben.

Mir wäre es lieber, wenn du auf ein Ceterum censeo verzichten würdest.

Mir wäre es lieber, wenn das Forum für viele Fälle brauchbare Voreinstellungen hätte und man auf Schnellschüsse bei Änderungen verzichten würde.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Da HTML (wenn nicht in XML-Syntax geschrieben) nicht case-sensitiv ist, ist die Frage nach CamelCase in HTML müßig. Man könnte tBody etc. schreiben; üblich ist das aber nicht. - hingegen ist in HTML durchaus üblich: bspw. bei data-*- und aria-*-Attributbezeichnern.

Richtig.

Auch CSS ist nicht case-sensitiv, was die Bezeichner der Eigenschaften angeht. Allerdings ist - dort weit verbreitet.

Auch richtig.

Was kümmern einen HTML/CSS-Entwickler Konventionen aus Programmiersprachen?

Nichts.

Aber: ein Programmiersprachen-Erfahrener HTML-/CSS-Entwickelnder wird sich eventuell trotzdem an dem orientieren, was er woanders auch benutzt.

Es sollten doch vielmehr Konventionen gelten, die HTML und CSS bereits eigen sind. Auch das spricht für die Verwendung von -, nicht CamelCase.

Ja.

Wenns darum geht, eine Konvention zu finden, hast du völlig recht. Wenns nur darum geht, zu erklären, wie man auf die Schreibweise kommt (und darum gings Martin, wenn ich ihn recht verstanden hab) ist die Erklärung über JS-Konventionen ja legitim :D

Abgesehen davon, dass ich jederzeit fromDuskTillDawn dem optisch weniger kompakten from-dusk-till-dawn vorziehen würde. […] Mir wäre im Beispiel die Kompaktheit wichtiger als die Lesbarkeit.

Mit dem Argument könntest du ja gleich fromdusktilldawn schreiben.

Richtig, nur, dass dann fromDuskTillDawn bei gleicher Kompaktheit lesbarer ist als fromdusktilldawn - aber ich schätze das war dir klar und die Aussage vor allem provokativ :P

Mir wäre es lieber, wenn du auf ein Ceterum censeo verzichten würdest.

Mir wäre es lieber, wenn das Forum für viele Fälle brauchbare Voreinstellungen hätte und man auf Schnellschüsse bei Änderungen verzichten würde.

1. lenkst du vom Thema meiner Aussage ab, 2. hast du grundsätzlich Recht, 3. muss man manchmal auch einfach was testen um zu sehen ob es sich bewährt und die Teilnahme an dedizierten Testumgebungen hat sich in der Vergangenheit als mangelhaft bewiesen ;)

Grüße,

RIDER

[Der Martin]

Hallo,

Wenns darum geht, eine Konvention zu finden, hast du völlig recht. Wenns nur darum geht, zu erklären, wie man auf die Schreibweise kommt (und darum gings Martin, wenn ich ihn recht verstanden hab) ist die Erklärung über JS-Konventionen ja legitim :D

legitim ist sie natürlich, aber unbefriedigend. "Weil die das im Nachbarort auch so machen" genügt mir nicht als Erklärung. Wenn jemand zur Erklärung auf Javascript verweist, müsste derjenige auch erläutern, warum das da in der Form eingeführt wurde.

Denn wie gesagt: CamelCase mit kleinem Anfangsbuchstaben sieht für mein Empfinden irgendwie "kaputt" aus, wie ein Versehen, ein Tippfehler.

So long,
 Martin

[Rolf b]

Hallo Martin,

die Konvention, bestimmte Dinge mit kleingeschriebenen Namen und andere Dinge mit großgeschriebenen Namen zu benennen, ist aber für Dich nachvollziehbar? Zum Beispiel - mal unabhängig von JS oder CSS - lokale Variablen mit kleinem Anfangsbuchstaben, und öffentliche Dinge (Klassennamen, Methodennamen) mit einem Großbuchstaben? Bei mir auf der Arbeit ist das Vorgabe und ich kenne es kaum anders, daher tut es mir eher weh wenn ich eine lokale Variable sehe die "Hugo" heißt statt "hugo".

So, und dann kommt das Problem der lesbaren Namen hinzu, was meine lieben COBOL Kollegen, die mit einem Alphabet ohne Kleinbuchstaben groß geworden sind, mit dem Minuszeichen lösen, d.h. dort schreiben sie "ANZ-PERSONEN" und ich in C# benenne dann dieses Feld in der Schnittstelle zum Großrechner in ein Property "AnzPersonen" um. Wer lieber kompakt schreibt, dem kommen BinnenMajuskeln einfach als eine prima Idee vor.

Kombiniert man Binnenmajuskeln mit der Regel für "Namen dieser Art schreibt man klein", dann ist camelCasing dieser Art unvermeidbar. Darum wird bei uns der Begriff "camelCase" auch immer nur für genau diese Schreibweise benutzt, und das, was Dir besser gefällt, heißt bei uns PascalCase (diese Begriffstrennung findest Du auch in der englischen Wikipedia unter "PascalCase"; der en-Wiki Beitrag zu CamelCase definiert CC als Sammelbegriff für Worte mit Binnenmajuskeln.

Soviel zur Herkunft der vermaledeitenCamelCaseBenenennerei :)

Ob es nun eine "international anerkannte" Schreibweise für CSS Klassen gibt, ist eine ganz andere Frage; wenn man sich diverse Klassenbibliotheken und Web-Texte anschaut, scheint Kleinschrift mit Minuszeichen so selten nicht zu sein. Klassennamen in camelCase habe ich auch gesehen, in PascalCase dagegen eher nicht. Für die Schreibweise mit Minuszeichen spricht auch CSS selbst, weil alle Style-Namen und auch die Pseudoklassen nach dieser Konvention benannt sind.

Gruß Rolf

[Der Martin]

Moin,

die Konvention, bestimmte Dinge mit kleingeschriebenen Namen und andere Dinge mit großgeschriebenen Namen zu benennen, ist aber für Dich nachvollziehbar?

bekannt ja, nachvollziehbar nein.

Zum Beispiel - mal unabhängig von JS oder CSS - lokale Variablen mit kleinem Anfangsbuchstaben, und öffentliche Dinge (Klassennamen, Methodennamen) mit einem Großbuchstaben? Bei mir auf der Arbeit ist das Vorgabe und ich kenne es kaum anders, daher tut es mir eher weh wenn ich eine lokale Variable sehe die "Hugo" heißt statt "hugo".

Ich bin seit jeher gewöhnt, möglichst aussagekräftige Bezeichner zu verwenden, der Verwendungszweck soll also klar daraus hervorgehen. Dann brauche ich die Schreibweise nicht als zusätzliche Metaebene und kann sie so wählen, dass sie dem wahren Leben möglichst nahe kommt.

Wer lieber kompakt schreibt, dem kommen BinnenMajuskeln einfach als eine prima Idee vor.

Da schließe ich mich auch vorbehaltlos an. Nur bin ich dann so konsequent, auch den Anfangsbuchstaben groß zu schreiben.

Soviel zur Herkunft der vermaledeitenCamelCaseBenenennerei :)

Okay. Jetzt ist mir der Hintergrund klar. Gut finden und nachmachen muss ich es aber nicht. ;-)

So long,
 Martin

[Matthias Apsel]

Hallo Rolf b,

Ob es nun eine "international anerkannte" Schreibweise für CSS Klassen gibt,

Wie kann es eine international anerkannte Schreibweise für etwas geben, was es nicht gibt? ;-)

Bis demnächst
Matthias

[JürgenB]

Hallo Matthias,

Wie kann es eine international anerkannte Schreibweise für etwas geben, was es nicht gibt? ;-)

wieso? Für Bielefeld gibt es sogar eine Seite bei der Wikipedia.

Gruß
Jürgen

[Rolf b]

Danke Gunnar. Jetzt habe ich Kopfschmerzen. Oder ist diese Pastell auf Pastell Darstellung ein Problem meines Handys? Lesen kann ICH da jedenfalls nichts. Vermutlich ist die Seite perfekt für aria gestaltet, nur die Normalsehenden haben Pech... (SCNR)

Rolf

[Gunnar Bittersmann]

@@Rolf b

Danke Gunnar. Jetzt habe ich Kopfschmerzen. Oder ist diese Pastell auf Pastell Darstellung ein Problem meines Handys? Lesen kann ICH da jedenfalls nichts. Vermutlich ist die Seite perfekt für aria gestaltet, nur die Normalsehenden haben Pech... (SCNR)

Das Problem ist bekannt. Das iPhone/Safari lässt sich von Impress.js nicht beeindrucken.

LLAP 🖖

[Rolf b]

Hallo Gunnar,

nach einiger Zeit habe ich jetzt verstanden wo das Problem ist. Das ist keine Webseite, sondern eine Menge von Slides wo man sich durchtappen muss. DAS muss man aber erstmal wissen. Und es funktioniert nicht nur unter unter Safari nicht, sondern unter Chrome für Android auch nicht.

Aber offenbar war das Web nicht das Medium, für das die Slides bestimmt waren, insofern ist die konsequente Unbedienbarkeit für Uneingeweihte wohl entschuldbar. Es wird sicher Tablets geben, wo sie gut funktionieren, und mit Desktop-Chrome und Pfeiltasten links/rechts kommt man durch. Wenn man es denn erstmal herausgefunden hat.

Rolf

[MinusKamel]

Für die Schreibweise mit Minuszeichen spricht auch CSS selbst, weil alle Style-Namen und auch die Pseudoklassen nach dieser Konvention benannt sind.

Das mag ja sein. Aber mancher Frontend-Macher (der sich selbst in der Rolle eines Nutzers der Spache sieht) dürfte weniger begeistert sein, wenn er in CSS und JS andere Notationsregeln befolgen soll. Und da das Minus-Zeichen in Javascript eben einen Versuch einer Berechnung auslöst und also in Bezeichnern nicht verwendet werden kann sehen diese keinerlei Vorteil darin, dieses in CSS dann doch zu tun.

[Gunnar Bittersmann]

@@Rolf b

mit dem Minuszeichen lösen …

Für die Schreibweise mit Minuszeichen spricht auch CSS selbst, weil alle Style-Namen und auch die Pseudoklassen nach dieser Konvention benannt sind.

Sag bitte nicht „Minuszeichen“ zum Bindestrich.

LLAP 🖖