/prog/ 8237: Hallo Bernd, du bist doch zufällig JS- und CSS-...

Hallo Bernd,

du bist doch zufällig JS- und CSS-Experte. Warum löst mein onclick auf dem Schließenbutton nicht aus? Ich vermute dass das div ihn irgendwie überdeckt, bin mir aber nicht sicher...

bitte kläre mich auf, Danke :3

>>8237
>36 Dateien

ICH WERDE DIESE DATEI NICHT KLICKEN.

Poste er den Quältext.

>>8238
>36 Dateien

FontAwesome :3

Der problematische Teil ist folgender:

var popupDiv;
var button;

button.onclick = function() {
alert(1);
}

popupDiv.appendChild(button);

var content = document.getElementById(id).innerHTML;
popupDiv.innerHTML = popupDiv.innerHTML + content; //<--- hier

irgendwie ist das onclick danach wek. Bernd hat es jetzt anders gelöst würde aber dennoch gerne wissen warum das so war.

Die Zeile ist Schuld:

box.innerHTML = box.innerHTML + content;

Du hast den Button vorher eingefügt, überschreibst ihn dann aber damit, sodass der gesetzte Handler nicht mehr funktioniert. Handler auf Properties sind sowieso bad practice, wenn du möchtest mach ich dir mal 'ne kleine Liste, was du alles besser machen kannst...

>>8240
>FontAwesome :3
>You loaded all 7 fontfaces of a shitty webfont just so you could say "Hi." at 100px height at the beginning of your site? You piece of shit.

>>8241

>Handler auf Properties sind sowieso bad practice

Sollte Bernd lieber einen Eventlistener auf dem Objekt selbst registrieren?

>wenn du möchtest mach ich dir mal 'ne kleine Liste, was du alles besser machen kannst...

Das wäre wunderbar :3


>>8242

Wenn es nach Bernd ginge würde er nur Websiten im Motherfucking-Stil erstellen. :3

auch: Was ist am wenigsten krebsig für kleine Symbole auf/für Buttons? jQueryUI, CSS-Sprites oder doch Webfonts?

>>8245
>Was ist am wenigsten krebsig für kleine Symbole auf/für Buttons? jQueryUI, CSS-Sprites oder doch Webfonts?

Gute Frage. Das Schlimme: Bei all diesen Lösungen wird extra was nachgeladen, oder?

Rein intuitiv würde Bernd sagen CSS-Sprites, weil dadurch theoretisch nur eine Bilddatei geladen werden muss, die Semantik von Buchstaben nicht zerstört wird und man mehrere Farben benutzen kann...

>>8245

>Sollte Bernd lieber einen Eventlistener auf dem Objekt selbst registrieren?

Entweder addEventListener nutzen oder - was hier m. E. besser passt - gleich jQuery. Da du sowieso jQuery eingebunden hast, kannst du es auch für Events & Co verwenden.

>Das wäre wunderbar :3

1. Du hast jQuery eingebunden, aber nutzt es kaum. Dinge wie "document.createElement", Event-Handling, CSS-Modifikation etc. sind mit jQuery viel einfacher. Außerdem ist jQuery nicht gerade klein. Wenn man es schon einbindet, sollte man es also auch nutzen (oder sich kleinere Alternativen suchen, wenn man kein reines (vanilla) JS schreiben will).

2. "onclick"-Attribute sollte man nicht nutzen, außer man nutzt ein Single-Page-App-Framework o. ä., wo Scoping gegeben ist. Verbesserung: Einfach mit jQuery "$('selector').on('click', function () { /*handler*/ })" usw...

3. Du erstellt einige Elemente unnötigerweise via JavaScript und weist ihnen dann auch noch diverse Styles zu. Verbesserung: Elemente im HTML und Styles im CSS definieren; Element per default ausblenden (display: hidden auf Selektor in CSS-Datei), dann via jQuery nur das Element aus-/einblenden (.show(), .hide()). Stichwort: Separation of Concerns. Was du aktuell machst ist, HTML und CSS mit JS abzubilden.

4. Wie bereits erwähnt, Events nicht auf Properties binden. Problem mit diesen ist, dass sie nur einmal verwendet werden können und etwaige, bereits vorher definierte Handler dann überschreiben. Bedenke jedoch, dass Handler immer auf Elemente gebunden werden; entfernst du diese oder tauscht sie aus, muss auch der Handler erneuert werden. Man kann mit jQuery Events auf document binden, um das zu umgehen. Sollte man aber nur machen, wenn man viel mit AJAX arbeitet und hier muss man dann aufpassen, Handler nicht zu häufig zu definieren.

5. Du arbeitest im globalen Scope. Verbesserung: z. B. $(function () { /*dein code*/ }) nutzen, was dann automatisch bei document.ready aufgerufen wird (was den Vorteil hat, dass dann alle Elemente da sind, egal wann du das JS einbindest).

6. JS solltest du in eine eigene Datei auslagern.

7. Keine inline-Styles nutzen, sondern CSS in eine Datei auslagern.

8. Nur ein Vorschlag: Statt des von dir genutzten module-Patterns könntest du dir mal Prototypes/Classes (letztere ES6) angucken. Finde die viel leserlicher, auch wenn sie den Nachteil fehlender Kapselung haben (finde jedoch, dass letztere oft überbewertet wird).

>Was ist am wenigsten krebsig für kleine Symbole auf/für Buttons? jQueryUI, CSS-Sprites oder doch Webfonts?

jQueryUI war vor vier Jahren oder so okay, heute ist es veraltet. Der Hauptgrund ist, dass es Pixelsymbole nutzt, Vektorfonts sind zwar auch kacke, aber definitiv überlegen. CSS-Sprites nutzen i. d. R. auch pixelbasierte Grafiken, falls ich da auf dem aktuellen Stand bin. Wenn man massentauglich entwickeln will, führt aktuell kein Weg an Webfonts vorbei. In Zukunft können wir dann hoffentlich SVG nutzen.

>>8248
>Dinge, die das Zeug in der Theorie in der Praxis minimal sauberer aber langsamer machen.

Tu es nicht, OP.
Nutz auch kein jQuery.

Achte lieber darauf, dass deine Webseite keine einzige Datei nachlädt. Das ist der einzige Grund, warum die Webseite des Dicken sofort da ist und Motherfucking Website mit ihrem Google Analytics-Gedrösel nicht...

Alles in eine Datei tun, der einzig richtige Weg, eine Webseite zu bauen!

>>8249

>Achte lieber darauf, dass deine Webseite keine einzige Datei nachlädt.

Willst du 4000 Zeilen JS in deinem HTML-Quellcode, nur um ein paar MS zu sparen? Wenn OP jetzt das neue Google bauen will, kann er sich einen Build-Prozess anlegen, der ihm eine entsprechende HTML-Datei ausgibt, ist aber größerer Aufwand. Für den Anfang reicht es definitiv, jQuery und andere scripts unmittelbar vor dem schließenden body-Tag einzubinden, wenn man großen Wert auf Geschwindigkeit legt (das geht aber nicht mit CSS, bzw. nicht sicher).

>Alles in eine Datei tun, der einzig richtige Weg, eine Webseite zu bauen!

Es ist richtig, dass man jQuery auch weglassen (oder Alternativen wie zepto nutzen) kann. Aber OP hat es nunmal eingebunden, daher meine Tipps. jQuery macht im Übrigen auch tatsächlich vieles einfacher und Code übersichtlicher, von daher ist das eine individuelle Entscheidung. Ich würde in den meisten Fällen auch heute noch jQuery nutzen, aber sicher kein jQueryUI.

Es scheint mir übrigens so zu sein, dass du nie in der Web-Programmierung gearbeitet hast - sonst wärst du wohl etwas pragmatischer.

>>8250
Das ist ja alles schön und gut aber Autismus, überhaupt zu antworten.

>>8250
Und was hältst du von Kaffeeskript?

>>8291

Ich persönlich mag die Syntax nicht und habe daher nie damit gearbeitet. Soll aber wohl ganz brauchbar sein.

>>8249
>Achte lieber darauf, dass deine Webseite keine einzige Datei nachlädt. Das ist der einzige Grund, warum die Webseite des Dicken sofort da ist und Motherfucking Website mit ihrem Google Analytics-Gedrösel nicht...
Äh, nein. Es sei denn OP baut eine SinglePageApp, aber dann hat er eh größere Probleme.

CSS & Javascript können zusammen schon gerne mal deutlich über 100KB ausmachen (wenn man viele Bibliotheken verwendet auch gerne mal 1MB). Die jedes Mal zu laden, dauert (und man saugt den Mobilnutzern unnötig Volumen weg). Lerne inzu Cache und 304 Not-Modified.