Stilfrage

[Christian]

Guten Morgen,

ich habe eine kleine Stilfrage. Ich habe eine RESTful-Software mit Laravel geschrieben, welche wiederum zum Löschen entsprechende POST-Forms benötigt. Der Nutzer wird mit einem modalen Dialog gefragt, ob er das Element wirklich löschen möchte. Das habe ich zurzeit so umgesetzt, dass ein form-Element in einem hidden-div in die Seite eingebaut ist. Nun bin ich am überlegen, ob es stilmäßig nicht besser wäre, diese zur Laufzeit sobald sie benötigt werden zum DOM hinzuzufügen und anschließend wieder zu entfernen. Allerdings glaube ich, dass letzteres umständlicher und unperformanter wäre.

Wie würdet ihr es machen und warum?

Besten Dank

[dedlfix]

Tach!

Nun bin ich am überlegen, ob es stilmäßig nicht besser wäre, diese zur Laufzeit sobald sie benötigt werden zum DOM hinzuzufügen und anschließend wieder zu entfernen. Allerdings glaube ich, dass letzteres umständlicher und unperformanter wäre.

Bei einem einzelnen Dialog kommt es darauf nicht an. Die Verarbeitungszeit geht im Grundrauschen unter.

Wie würdet ihr es machen und warum?

So wie ich es am besten bearbeiten kann. Das heißt, der Code kommt ins Dokument, dann kann ich ihn wie den restlichen Code mit den Mitteln meiner Entwicklungsumgebung bearbeiten und habe ihn nicht als Stringliteral oder aus tausend createElement/insert/append-Anweisungen rumliegen.

dedlfix.

[Christian]

Guten Tag!

Bei einem einzelnen Dialog kommt es darauf nicht an. Die Verarbeitungszeit geht im Grundrauschen unter.

Im schlimmsten Fall sind es 3 Dialoge, da ich das gleiche hidden-form für verschiedene Entities nutze.

So wie ich es am besten bearbeiten kann. Das heißt, der Code kommt ins Dokument, dann kann ich ihn wie den restlichen Code mit den Mitteln meiner Entwicklungsumgebung bearbeiten und habe ihn nicht als Stringliteral oder aus tausend createElement/insert/append-Anweisungen rumliegen.

Ja, dieses Gefrickel mit createElement und co. wäre auch schon ganz schön unschön.

Danke für deine Antwort!

[Reinhard]

Hey,

So wie ich es am besten bearbeiten kann. Das heißt, der Code kommt ins Dokument, dann kann ich ihn wie den restlichen Code mit den Mitteln meiner Entwicklungsumgebung bearbeiten und habe ihn nicht als Stringliteral oder aus tausend createElement/insert/append-Anweisungen rumliegen.

Angenommen ich habe ein Elternelement - ob bereits im DOM oder mit createElement erzeugt -, was spräche für das Erzeugen der Struktur mittels createElement / appendChild und was gegen innerHTML und ein (wenn nötig) dynamisches Nachbearbeiten mit parent.children[x].children[y] / getElement(s)By...?

Reinhard

[dedlfix]

Tach!

Angenommen ich habe ein Elternelement - ob bereits im DOM oder mit createElement erzeugt -, was spräche für das Erzeugen der Struktur mittels createElement / appendChild und was gegen innerHTML und ein (wenn nötig) dynamisches Nachbearbeiten mit parent.children[x].children[y] / getElement(s)By...?

Ob es generelle technische Gründe für das eine oder das andere gibt, weiß ich nicht. Ich würde das bei Bedarf anhand von Aufgabenstellung und Aufwand entscheiden.

Aber für mich wird sich solch eine Frage nur selten stellen, denn eigentlich arbeite ich wenn immer möglich mit AngularJS, da ist die Herangehensweise eh eine andere. Mit den genannten Funktionen käme man da nur in Berührung, wenn man eine Direktive schreiben müsste. Das muss man nur, wenn man Manipulationen am DOM vornehmen muss, die nicht durch die bereits vorhandenen anderen Wege abgedeckt sind.

dedlfix.

[Gunnar Bittersmann]

@@Christian

Der Nutzer wird mit einem modalen Dialog gefragt, ob er das Element wirklich löschen möchte. Das habe ich zurzeit so umgesetzt, dass ein form-Element in einem hidden-div in die Seite eingebaut ist.

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element.

Wie würdet ihr es machen und warum?

Initial in HTML, mit hidden-Attribut.

LLAP 🖖

[Christian]

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element.

Danke für die Information. Ich werde es in Zukunft in Betracht ziehen. Zurzeit nutze ich Bootstraps modalen Dialog, der nutzt wohl noch div-Elemente. Ich schätze, dass sich das mit Version 4 ändern wird.

Wie würdet ihr es machen und warum?

Initial in HTML, mit hidden-Attribut.

Alles klar!

Vielen Dank für deine Antwort!

Lebe lang und in Frieden.

[dedlfix]

Tach!

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element. Danke für die Information. Ich werde es in Zukunft in Betracht ziehen. Zurzeit nutze ich Bootstraps modalen Dialog, der nutzt wohl noch div-Elemente. Ich schätze, dass sich das mit Version 4 ändern wird.

Welche Elemente du bei Bootstrap verwendest, spielt meist weniger die Rolle. Du kannst da ruhig auch passendere als div verwenden. Das Styling entscheidet sich vorwiegend anhand der Klassennamen. Vermutlich nehmen die in ihren Beispielen nur deshalb divs, weil damit auch die hornalten Browser umgehen können.

Übrigens, auch drei Dialoge machen das Kraut nicht fett. Da musst du schon deutlich größere Kalieber auffahren, beispielsweise ein Grid mit vielen Zeilen und/oder Spalten.

dedlfix.

[Christian]

Welche Elemente du bei Bootstrap verwendest, spielt meist weniger die Rolle. Du kannst da ruhig auch passendere als div verwenden. Das Styling entscheidet sich vorwiegend anhand der Klassennamen. Vermutlich nehmen die in ihren Beispielen nur deshalb divs, weil damit auch die hornalten Browser umgehen können.

Stimmt, ich habe nicht nachgedacht. Ich hatte den Markup aus den Beispielen einfach kopiert und eingefügt, natürlich kann ich die divs einfach ersetzen... Dankeschön.

Übrigens, auch drei Dialoge machen das Kraut nicht fett. Da musst du schon deutlich größere Kalieber auffahren, beispielsweise ein Grid mit vielen Zeilen und/oder Spalten.

Ja das ist natürlich klar, aber ich denke man kann sich auch im kleinen Stil einen guten Programmierstil angewöhnen. :-)

Besten Dank!

[Gunnar Bittersmann]

@@Christian

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element. Danke für die Information. Ich werde es in Zukunft in Betracht ziehen. Zurzeit nutze ich Bootstraps modalen Dialog, der nutzt wohl noch div-Elemente.

Bei Bootcrap wird doch die visuelle Darstellung über Klassen geregelt. Du solltest im Markup div in dialog ändern können, ohne dass sich die visuelle Darstellung ändert.

Eventuell noch dialog { display: block } ins Stylesheet.

Ich schätze, dass sich das mit Version 4 ändern wird.

Da würde ich nicht drauf wetten.

Wenngleich die Frameworks in Sachen Barrierefreiheit schon besser werden.

LLAP 🖖

[Christian]

Bei Bootcrap wird doch die visuelle Darstellung über Klassen geregelt. Du solltest im Markup div in dialog ändern können, ohne dass sich die visuelle Darstellung ändert.

Eventuell noch dialog { display: block } ins Stylesheet.

Du scheinst kein Freund von Bootstrap zu sein? :) Es war für den Zeitaufwand die beste Wahl. Das ist eine Ausarbeitung für eine Hausarbeit in der Hochschule. Dort war die Funktionalität wichtiger als das "Design", daher habe ich der Einfachheit halber das genommen. Was schlägst du denn vor, lieber alles von Grund auf selbst entwickeln?

Da würde ich nicht drauf wetten.

Wenngleich die Frameworks in Sachen Barrierefreiheit schon besser werden.

Danke für deine Einschätzung!

[Gunnar Bittersmann]

@@Christian

Du scheinst kein Freund von Bootstrap zu sein?

Ich bin ein Freund von separation of concerns: HTML zur Strukturierung des Inhalts; CSS für die Präsentation. Ich bin kein Freund von präsentationsbezogenem Markup. Also kein Freund von Bootstrap.

Bootstrap ist für Projekte, wo kein Frontend-Entwickler zur Verfügung steht. Ich bin aber Frontend-Entwickler.

Bootstrap ist nichts für Frontend-Entwickler. Wie der Erklärbär so schön sagte: „Bootstrap ist das IKEA der Webentwicklung.“

Ich hab Bootstrap bei einem Vortrag eine eigene Folie gewidmet.

Es war für den Zeitaufwand die beste Wahl.

Das mag für dein Projekt durchaus so sein.

LLAP 🖖

[Christian]

Herzlichen Dank für deine Antwort, ich werde mir die Links anschauen.

Lebe lang und in Frieden!

[Pascal]

Hi!

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element.

Aber welcher Browser unterstützt das wie definiert? Laut https://developer.mozilla.org/en/docs/Web/HTML/Element/dialog bisher nur Chrome.

Bei Bootcrap wird doch die visuelle Darstellung über Klassen geregelt. Du solltest im Markup div in dialog ändern können, ohne dass sich die visuelle Darstellung ändert.

Das denke ich nicht.... In Browsern die dialog unterstützen bringt das Element eigene Styles mit sich. Die beißen sich wahrscheinlich mit Bootstrap:

http://w3c.github.io/html/rendering.html#non-replaced-elements-flow-content

Eventuell noch dialog { display: block } ins Stylesheet.

Das leuchtet mir nicht ein. Ohne "open" Attribut sollte <dialog> standardmäßig versteckt sein. Man sollte besser "open" setzen, um es zu zeigen. Dazu würde ich die verlinkten Styles benutzen und wenn nötig anpassen:

dialog:not([open]) { display: none; }
dialog { display: block; usw. }

<dialog> ist eine coole Erfindung. Bloß glaube ich nicht dass es sich mit Bootstrap Modals vereinbaren lässt. Dazu müsste Bootstrap die Browserstyles passend überschreiben.

Außerdem setzt Bootstrap tabindex ein damit das Element fokussierbar ist. Nur: "The tabindex attribute must not be specified on dialog elements."

Man sollte vorsichtig damit sein noch nicht unterstützte Elemente statt <div>s zu verwenden. Wenn die Browser sie irgendwann unterstützen, bekommen sie plötzlich eine neue Bedeutung und Styles hinzu.

Wenngleich die Frameworks in Sachen Barrierefreiheit schon besser werden.

Nur am Rande, die Modals in Bootstrap sind barrierefrei soweit ich weiß. Tabindex Fokus, ARIA Rolle, ARIA Label usw.

Mit <dialog> wird das zum Glück bald einfacher aber bis dahin ist das die beste Lösung.

Pascal

[Rolf b]

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element.

Wirklich? Das ist noch arg rot -> caniuse.

[Matthias Apsel]

Hallo Rolf b,

Ein modalen Dialog wäre besser kein div, sondern ein dialog-Element.

Wirklich? Das ist noch arg rot -> caniuse.

Die entscheidende Frage ist, welche Einbußen an Funktionalität entstehen, wenn ein Browser das dialog-Element nicht kennt. In diesem Fall würde ich die Frage mit „keine“ beantworten.

Bis demnächst
Matthias

[Pascal]

Hi,

Die entscheidende Frage ist, welche Einbußen an Funktionalität entstehen, wenn ein Browser das dialog-Element nicht kennt. In diesem Fall würde ich die Frage mit „keine“ beantworten.

Freilich kann man <dialog> bereits jetzt verwenden aber die Bedienbarkeit und Accessibility sollte in allen Browser gut sein.

Bei dieser CSS Lösung mit :target frage ich mich, wie steht es mit der Accessibility? Wurde das untersucht?

Um sicher zu gehen besser den vollwertigen Javascript Polyfill verwenden.

Pascal

[Matthias Apsel]

Hallo Pascal,

Freilich kann man <dialog> bereits jetzt verwenden aber die Bedienbarkeit und Accessibility sollte in allen Browser gut sein.

Sie leidet nicht (wenn man es nicht selbst verbockt). Ohne Unterstützung von dialog ist es ein normales Formular.

Bis demnächst
Matthias