Mit jquery html-Datei nachgeladen, JS-Problem
0 
J o
0 
Rolf B
1 
Gunnar Bittersmann
Mit jquery html-Datei nachgeladen, JS-Problem
Tabellenkalk
AugeHi, ich arbeite mich grad in html, js & co ein.
Dabei habe ich ein Problem, bei dem ich noch keine Lösung gefunden hab.
Ich habe eine "Seite1"-Html-Datei. In dieser Seite1 ist auch der Verweis auf die JS-Datei. Von dieser Seite1 wird per JQuery eine "Seite2"-Html-Datei in die Seite1 nachgeladen. Die Seite2 enthält ein Formular. Ich würde nun gerne mit JQuery das Submit des Formulars abfangen. Wie kann ich es anstellen, daß meine Script-Datei auch auf nachgeladene Html-Elemente reagiert?
Gruß Fritziiiii
html-Datei1
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<script type="text/javascript" src="jquery-3.3.1.js"></script>
<script src="script.js"></script>
<title>Insert title here</title>
</head>
<body>
<div id ="haupt_div">
<p> </p>
<label id ="Inhalt_nachladen" >Inhalt nachladen</label>
<div id = "container" >
</div>
</div>
</body>
</html>
html-Datei2
<form id = "form_xy">
<input type="text" id="eingabe" name="eingabe" /><br />
<input id="button_submit" value="Übernehmen" type="submit" />
</form>
JS-Datei
$(document).ready(function(){
$("#Inhalt_nachladen").click(function(){
$("#container").load("seite2.html");
$("p").html("test");
})
$("#form_xy").submit(function(){
alert("blub");
$("p").html = $("#eingabe").val();
return false;
})
});
-
Moin,
[...] Ich würde nun gerne mit JQuery das Submit des Formulars abfangen. Wie kann ich es anstellen, daß meine Script-Datei auch auf nachgeladene Html-Elemente reagiert?
Schau dir mal
.delegate()an.Dein Problem ist, dass das Element auf das du den Eventlistener registrieren möchtest noch nicht im DOM vorhanden ist und deshalb nicht funktioniert.
Oder du registrierst den Eventlistener sobald der Content von dem
.load()nachgeladen wurde.Gruß
Jo-
Hallo Jo und fritziii,
.delegate() ist veraltet und seit jQuery 3 missbilligt. submit oder on("submit") ist richtig.
Für fritziii wichtig zu wissen ist hier, dass .load asynchron arbeitet, d.h. die Befehle die dahinter programmiert sind laufen ab bevor das Form vorhanden ist.
Für die Registrierung kann man entweder das submit-Event bei #container registrieren, dann bubbelt es dahin, oder den 2. Parameter von .load nutzen um einen Callback zu hinterlegen der aufgerufen wird sobald load fertig ist.
Rolf
--
sumpsi - posui - clusi
-
-
@@fritziiiii
Hi, ich arbeite mich grad in html, js & co ein.
Ganz ehrlich: Wenn du dich gerade einarbeitest, dann lerne JavaScript, nicht jQuery.
jQuery ist eine Bibliothek, die in der Vergangenheit einmal sehr nützlich war und die Weiterentwicklung von JavaScript beeinflusst hat und sich damit selbst überflüssig gemacht hat. Soll heißen: All die nützlichen Dinge von jQuery gibt es heute auch ohne jQuery, und das weitaus besser.
<label id ="Inhalt_nachladen" >Inhalt nachladen</label>Das
label-Element ist für die Beschriftung eines Eingabe-Elements (bzw. Ausgabe-Elements) gedacht; nicht für ein Eingabe-Element selbst. Es ist nicht interaktiv; das funktioniert so nicht – nicht bei Bedienung mit Tastatur.Für Aktionen (also für so ziemlich alles, worauf du
click-Eventhandler anwenden willst) muss dubuttons verwenden:<button id="Inhalt_nachladen">Inhalt nachladen</button>LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
All die nützlichen Dinge von jQuery gibt es heute auch ohne jQuery, und das weitaus besser.
wirklich all die nützlichen Dinge von jQuery? Nein, ein Datepicker und ein Clockpicker sind für mich nach wie vor mit Vanilla-JS nicht machbar. Die browsereigenen Widgets für
<input type="date">und<input type="time">sind in meinen Augen längst noch nicht so gut wie diese jQuery-Plugins. Und das ist für mich ebenso schade wie unverständlich!Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
wirklich all die nützlichen Dinge von jQuery? Nein, ein Datepicker und ein Clockpicker sind für mich nach wie vor mit Vanilla-JS nicht machbar. Die browsereigenen Widgets für
<input type="date">und<input type="time">sind in meinen Augen längst noch nicht so gut wie diese jQuery-Plugins. Und das ist für mich ebenso schade wie unverständlich!Die nativen Datepicker sind weitaus besser als so ziemlich alles Gefrickel. Ich weiß nicht, was daran für dich unverstandlich ist.
Der von dir gezeigte Datepicker ist auf dem Desktop unbedienbar. Ich habe jedenfalls nicht herausgefunden, mit welchen Tasten das gehen soll. Tab springt zum nächsten Element; Leertaste und Pfeiltasten tun gar nichts. Ergo: unbrauchbarer Scheiß.
Und was soll ich mit dem Ding auf dem iPhone? Winzige, eng beieinander liegende Schaltflächen. So sieht ein vernünftiger Datepicker dort aus:
JavaScript-Datepicker sind so 2013.
<input type="date">ist modern.LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
Der von dir gezeigte Datepicker ist auf dem Desktop unbedienbar. [...] mit welchen Tasten [...] Ergo: unbrauchbarer Scheiß.
LOL - Genau das habe ich erwartet. Daher habe ich den Epiphany-Webbrowser angeworfen, der mit der Webkit-Engine. Dort habe ich sowohl in
type="date"als auchtype="time"geklickt - und nichts ist passiert. Kein GUI, keine Tastaturunterstützung - unbedienbar!Dann habe ich
type="time"im FF ausprobiert. Mit den Tasten kann man etwas sinnvolles eingeben, mit der Maus nicht. Unbedienbar!JavaScript-Datepicker sind so 2013.
<input type="date">ist modern.Das ist genau mein Problem! Es ist so modern, dass es in manchen Browsern einfach noch nicht unterstützt wird. Daher muss ich mich im Zweifelsfalle eben doch auf JS-Picker verlassen, denn die haben im Epiphany so funktioniert, wie sie das in anderen Browsern auch tun. Und wenn die Ersteller dann noch eine gute/geeignete Tastaturbenutzung implementieren, dann kann man das auch für die nativen Browser-Widgets empfehlen. Der FF bietet beim Datum immerhin eine Kalender-Ansicht an. Bei der Zeitauswahl leider nichts...
Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
Daher habe ich den Epiphany-Webbrowser angeworfen,
Hervorragende Idee, bei einer Diskussion zu Bedienbarkeit allgemein irgendeinen Browser-Exoten anzuführen. Nicht.
Dort habe ich sowohl in
type="date"als auchtype="time"geklickt - und nichts ist passiert. Kein GUI, keine Tastaturunterstützung - unbedienbar!?? Mit „kein GUI“ meinst du wohl: kein Date- bzw. Timepicker, sondern normale Texteingabefelder als Fallback‽ Also volle Bedienbarkeit‽
Das ist genau mein Problem! Es ist so modern, dass es in manchen Browsern einfach noch nicht unterstützt wird.
Texteingabefelder werden in allen Browsern unterstützt.
Du hast nach all den Jahren, wo wir schon darüber reden, progressive enhancement immer noch nicht verstanden? Genau das ist dein Problem.
Dann habe ich
type="time"im FF ausprobiert. Mit den Tasten kann man etwas sinnvolles eingeben, mit der Maus nicht. Unbedienbar!Geht doch: 🤪
Daher muss ich mich im Zweifelsfalle eben doch auf JS-Picker verlassen, denn die haben im Epiphany so funktioniert, wie sie das in anderen Browsern auch tun.
Eben nicht! Kein Nutzer vergleicht, ob Webseiten in verschiedenen Browsern exakt gleich aussehen. Do websites need to look exactly the same in every browser .com solltest du inzwischen kennen.
Nutzern fällt aber unangenehm auf, wenn ein UI-Element in ihrem Browser/auf ihrem Gerät nicht so funktioniert, wie sie von ihrem Browser/ihrem Gerät gewöhnt sind. Wie das bspw. bei einem JS-Datepicker auf einem iPhone der Fall ist.
Und wenn die Ersteller dann noch eine gute/geeignete Tastaturbenutzung implementieren, dann kann man das auch für die nativen Browser-Widgets empfehlen.
Ja – wenn. Bei dem Datepicker, um den es im verlinkten Posting ging, war die Tastaturbedienbarkeit gegeben. (Wie gesagt, Screenreadertauglichkeit hatte ich nicht getestet.) Im Gegensatz zu dem von dir gezeigtem Datepicker, der für die Tonne ist.
Das Problem ist, dass viele JavaScript-Entwickler von den Gundlagen der Frontend-Entwicklung (sprich: von HTML, CSS, inklusivem Design, Barrierefreiheit) nicht die geringte Ahnung haben. Und wenn ich sage viele, dann meine ich die meisten. Dass die sich dann auch noch „Frontend-Entwickler“ nennen, ist ein Witz. Ein schlechter.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
Hervorragende Idee, bei einer Diskussion zu Bedienbarkeit allgemein irgendeinen Browser-Exoten anzuführen. Nicht.
Du wolltest doch Benutzbarkeit in allen Browsern! Naja, ein reines Textfeld kann man mit der Maus alleine eben nicht bedienen.
?? Mit „kein GUI“ meinst du wohl: kein Date- bzw. Timepicker, sondern normale Texteingabefelder als Fallback‽ Also volle Bedienbarkeit‽
Volle Bedienbarkeit bei nur-Mauseingabe halte ich für nicht "voll". Bei Zahlenfeldern kann man mit Pfeilchenbuttons höher und niedriger einstellen - bei Zeiteingaben nicht. Warum eigentlich nicht?
Du hast nach all den Jahren, wo wir schon darüber reden, progressive enhancement immer noch nicht verstanden? Genau das ist dein Problem.
Vielleicht stelle ich nur "unmögliche" Forderungen nach "voller" Bedienbarkeit. Mouse-only zähle ich dazu.
Kein Nutzer vergleicht, ob Webseiten in verschiedenen Browsern exakt gleich aussehen.
Darum ging es nicht, sondern darum, dass ohne passendes GUI vom Browser eine reine Mauseingabe eben nicht gelingt.
Do websites need to look exactly the same in every browser .com solltest du inzwischen kennen.
Ja, kenne ich, geht aber in eine völlig andere Richtung. Ich will Datum und Zeit alleine mit der Maus eingeben können. In allen Browsern.
Nutzern fällt aber unangenehm auf, wenn ein UI-Element in ihrem Browser/auf ihrem Gerät nicht so funktioniert, wie sie von ihrem Browser/ihrem Gerät gewöhnt sind. Wie das bspw. bei einem JS-Datepicker auf einem iPhone der Fall ist.
Von mir aus kannst Du den Datepicker aus meinen Forderungen entschärfen, aber beim Timepicker mit nur-Mausbedienung (ohne Touch-Tastatur!) bleibe ich!
Und wenn die Ersteller dann noch eine gute/geeignete Tastaturbenutzung implementieren, dann kann man das auch für die nativen Browser-Widgets empfehlen.
Ja – wenn. Bei dem Datepicker, um den es im verlinkten Posting ging, war die Tastaturbedienbarkeit gegeben. (Wie gesagt, Screenreadertauglichkeit hatte ich nicht getestet.) Im Gegensatz zu dem von dir gezeigtem Datepicker, der für die Tonne ist.
Und bei Timepickern? Warum lässt Du diese wieder unter den Tisch fallen? Keine Argumente in der Schublade? ;-P
Das Problem ist, dass viele JavaScript-Entwickler von den Gundlagen der Frontend-Entwicklung (sprich: von HTML, CSS, inklusivem Design, Barrierefreiheit) nicht die geringte Ahnung haben. Und wenn ich sage viele, dann meine ich die meisten. Dass die sich dann auch noch „Frontend-Entwickler“ nennen, ist ein Witz. Ein schlechter.
OK, dann erzählen wir hier besser keine Witze, sondern suchen allen Ernstes nach einem Timepicker, der sowohl rein mit der Tastatur, als auch rein mit der Maus benutzbar ist. Bei exotischen Browsern benutzen wir dann eine Schutzbehauptung, dass User mit Textfeldern unter allen Umständen umgehen können müssen - passendere Widgets gibt es nur für Mainstream-Browser, die wir als "moderne Browser" anerkennen.
Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
Naja, ein reines Textfeld kann man mit der Maus alleine eben nicht bedienen.
Das Gegenteil hatte ich bereits mit einem Screenshot gezeigt. Virtuelle Tastatur – mausbedienbar.
(Steven Hawking hatte seinen Sprachsynthesizer auch mit einem Zeigegerät bedient.)
Bei Zahlenfeldern kann man mit Pfeilchenbuttons höher und niedriger einstellen - bei Zeiteingaben nicht. Warum eigentlich nicht?
Willst du bei Zeiteingaben für die Minute bis zu 59 Mal auf einen Pfeil clicken? Nein? Das beantwortet dann wohl die Frage, warum keine Pfeiltasten vorgesehen sind.
Auf dem iPhone gibt es auch für
<input type="time">die dort üblichen Walzen wie beim einarmigen Banditen. Und wie bei der Datumseingabe will ich da kein anderes UI-Element als das native haben.
OK, dann erzählen wir hier besser keine Witze, sondern suchen allen Ernstes nach einem Timepicker, der sowohl rein mit der Tastatur, als auch rein mit der Maus benutzbar ist.
Wenn dir der native Timepicker deines Browsers nicht gefällt, dann mach ein Ticket mit einem Verbesserungsvorschlag auf.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Hallo,
Willst du bei Zeiteingaben für die Minute bis zu 59 Mal auf einen Pfeil clicken?
maximal 30mal, wenn man auch einmal die Stunde anpassen darf.
Nein? Das beantwortet dann wohl die Frage, warum keine Pfeiltasten vorgesehen sind.
Bei meiner Maus kann man die Taste gedrückt halten, so dass sich die Anzahl der Klicks noch weiter sehr reduziert…
Gruß
Kalk-
Hallo
Willst du bei Zeiteingaben für die Minute bis zu 59 Mal auf einen Pfeil clicken?
maximal 30mal, wenn man auch einmal die Stunde anpassen darf.
Also eventuell 31 mal. Das wäre mir schon zuviel. Da sind die paar Tastendrücke für die Eingabe einer Uhrzeit viel bequemer. Auf einem Mobilgerät sieht das mit der Walzenscrolleingabe natürlich anders aus.
Nein? Das beantwortet dann wohl die Frage, warum keine Pfeiltasten vorgesehen sind.
Bei meiner Maus kann man die Taste gedrückt halten, so dass sich die Anzahl der Klicks noch weiter sehr reduziert…
Das läuft dann aber unter Zufallsgenerator. „Oh, vorbei. Also wieder ein paar Klicks zurück …“ 😀
Tschö, Auge
--
Eine Kerze stand [auf dem Abort] bereit, und der Almanach des vergangenen Jahres hing an einer Schnur. Die Herausgeber kannten ihre Leser und druckten den Almanach auf weiches, dünnes Papier.
Kleine freie Männer von Terry Pratchett-
Liebes Auge,
Auf einem Mobilgerät sieht das mit der Walzenscrolleingabe natürlich anders aus.
warum eigentlich nur dort? Das könnte man auch in PC-Browser implementieren. Ich verstehe nicht, warum man das nicht tut. Diese mit der Tastatur zu bedienen (die beiden (oder drei?) Walzen "durch-tabben" und dann eine Pfeil-auf- oder -runter-Taste gedrückt halten) ist ebenso sinnvoll lösbar.
Liebe Grüße,
Felix Riesterer.
-
-
-
-
-
@@Gunnar Bittersmann
Bei dem Datepicker, um den es im verlinkten Posting ging, war die Tastaturbedienbarkeit gegeben. (Wie gesagt, Screenreadertauglichkeit hatte ich nicht getestet.) Im Gegensatz zu dem von dir gezeigtem Datepicker, der für die Tonne ist.
Wobei man fairerweise sagen muss, dass bei dem von dir gezeigtem Datepicker als Fallback auch das Texteingabefeld zur Verfügung steht. Nur dass der nicht-tastaturbedienbare Datepicker davon ablenkt. Was angezeigt wird, muss auch bedienbar sein.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann -
@@Gunnar Bittersmann
Das Problem ist, dass viele JavaScript-Entwickler von den Gundlagen der Frontend-Entwicklung (sprich: von HTML, CSS, inklusivem Design, Barrierefreiheit) nicht die geringte Ahnung haben. Und wenn ich sage viele, dann meine ich die meisten. Dass die sich dann auch noch „Frontend-Entwickler“ nennen, ist ein Witz. Ein schlechter.
Und überhaupt scheinen CSS-Kenntnisse nicht allzuweit verbreitet zu sein. Nur ein kleiner Teil wusste bei diesem Quiz die richtige Antwort.
(Wobei die Motivation der Teilnehmer vermutlich zwischen „ich rate mal einfach drauf los“ und „ich versuche, das irgendwo nachzulesen“ schwankt.)
Die Ahnungslosen sind dann wohl auch diejenigen, die ständig „CSS is broken“ rufen.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
hallo
@@Gunnar Bittersmann
Das Problem ist, dass viele JavaScript-Entwickler von den Gundlagen der Frontend-Entwicklung (sprich: von HTML, CSS, inklusivem Design, Barrierefreiheit) nicht die geringte Ahnung haben. Und wenn ich sage viele, dann meine ich die meisten. Dass die sich dann auch noch „Frontend-Entwickler“ nennen, ist ein Witz. Ein schlechter.
Und überhaupt scheinen CSS-Kenntnisse nicht allzuweit verbreitet zu sein. Nur ein kleiner Teil wusste bei diesem Quiz die richtige Antwort.
Ich frage mich jetzt, warum ich CSS kennen muss, damit meine Seite zugänglich ist...
Betreffs Zugänglichkeit sind HTML und same-domain-policy relevant. Damit CSS relevant wird, musst du vorher schon einiges mit CSS angestellt haben.
-
@@beatovich
Ich frage mich jetzt, warum ich CSS kennen muss, damit meine Seite zugänglich ist...
Um zu wissen, was du mit CSS nicht tun darfst, weil du sonst was kaputtmachst. Beispiel
Das war aber hier nicht mein Punkt.
Sondern, dass das, was in der Industrie als „Frontend-Entwicklung“ bezeichnet wird (nämlich Anwendungs-Programmierung in JavaScript), nichts mit dem zu tun hat, was ich unter Frontend-Entwicklung verstehe. Und dass Anwendungs-Programmierer (sei es nun Java, PHP, JavaScript oder sonstwas) wenig bis keine Ahnung von HTML, CSS, inclusive design etc. haben.
Was auch verständlich ist; niemand kann alles wissen. Nur sollten sie dann nicht zusätzlich zu dem, was sie können, auch noch das tun, was sie nicht können: HTML und CSS schreiben. Man sollte da eine Trennung machen und neben Anwendungs-Programmierern auch Frontend-Entwickler beschäftigen.
Und letztere anders nennen, da der Begriff „Frontend-Entwicklung“ verbraucht ist.
Dann schweifte ich dahin ab, dass bei denen, die CSS entwicklen, Wissenslücken aufklaffen. Was auch verständlich ist; niemand kann alles wissen. Es scheint aber, dass allgemein keine allzu große Bereitschaft vorhanden ist, diese Lücken zu schließen.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
Und überhaupt scheinen CSS-Kenntnisse nicht allzuweit verbreitet zu sein. Nur ein kleiner Teil wusste bei diesem Quiz die richtige Antwort.
Die Ahnungslosen sind dann wohl auch diejenigen, die ständig „CSS is broken“ rufen.
Ich wünschte du würdest Entwicklern ähnlich viel Empathie entgegen bringen wie du sie für Endnutzer aufbringst. Wenn eine Benutzerschnittstelle unverständlich ist, dann ist das ein Indiz für schlechtes Design und die Schuld ist nicht bei den Nutzern zu suchen. Wenn Entwicklungs-Werkzeuge nicht verstanden werden, dann ist das ebenso ein Indiz für schlechtes Design. Wie dedlfix letztens sagte: Entwickler sind auch Nutzer. In dem Sinne: Ja, einige CSS-Features sind kaputt.
-
@@1unitedpower
Ich wünschte du würdest Entwicklern ähnlich viel Empathie entgegen bringen wie du sie für Endnutzer aufbringst.
“In case of conflict, I will always value user needs above developer convenience. That’s called ‘work’.” —Jeremy Keith
Ja, einige CSS-Features sind kaputt.
Ja, es gibt einige Unschönheiten in CSS. Dass
darkgrayheller ist alsgray, ist eine. Dass mehrere Angaben in einem Wert für verschiedene Eigenschaften mal durch Komma, mal durch Leerzeichen zu trennen sind, ist eine andere.Worüber aber am meisten gewettert wird, gehört nicht dazu: die Kaskade.
Dass die CSS-Denke anders ist als die Denke in Programmiersprachen, ist ein Feature, kein Bug.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
hallo
@@1unitedpower
Ich wünschte du würdest Entwicklern ähnlich viel Empathie entgegen bringen wie du sie für Endnutzer aufbringst.
“In case of conflict, I will always value user needs above developer convenience. That’s called ‘work’.” —Jeremy Keith
Ja, einige CSS-Features sind kaputt.
Ja, es gibt einige Unschönheiten in CSS. Dass
darkgrayheller ist alsgray, ist eine. Dass mehrere Angaben in einem Wert für verschiedene Eigenschaften mal durch Komma, mal durch Leerzeichen zu trennen sind, ist eine andere.Worüber aber am meisten gewettert wird, gehört nicht dazu: die Kaskade.
button{background:whatever}
Deine Aufgabe: fix it = restauriere den ursprünglichen Zustand.
-
@@beatovich
button{background:whatever}
Deine Aufgabe: fix it = restauriere den ursprünglichen Zustand.
Dass Browser bei Zuweisung eines Hintergrunds auch den Rahmen des Buttons verändern, ist nun nicht die Schuld von CSS.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
hallo
@@beatovich
button{background:whatever}
Deine Aufgabe: fix it = restauriere den ursprünglichen Zustand.
Dass Browser bei Zuweisung eines Hintergrunds auch den Rahmen des Buttons verändern, ist nun nicht die Schuld von CSS.
initial restauriert nicht den browser-Default. Es styletiert den button zu einem span.
Soll ich jetzt sagen, dass es auch dir an Bildung fehlt?
-
@@beatovich
initial restauriert nicht den browser-Default.
Wo du recht hast …
revertwäre das richtige Schlüsselwort. [Spec, MDN]Im Pen ergänzt. Funzt in Safari. [CanIUse]
Soll ich jetzt sagen, dass es auch dir an Bildung fehlt?
Sag das ruhig. Niemand kann alles wissen.
Aber danke, wieder was gelernt.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
hallo
@@beatovich
initial restauriert nicht den browser-Default.
Wo du recht hast …
revertwäre das richtige Schlüsselwort. [Spec, MDN]Im Pen ergänzt. Funzt in Safari. [CanIUse]
Soll ich jetzt sagen, dass es auch dir an Bildung fehlt?
Sag das ruhig. Niemand kann alles wissen.
Ich hab mal einen anonymen Pen gemacht
https://codepen.io/anon/pen/yQPrBB
lohnt sich, das auf dem Schirm zu behalten, denn da hätte ich effektiv Bedarf.
-
Hallo beatovich,
gibt's nun auch eine Möglichkeit, wieder zum Browserdefault zurückzukehren? Zumindest hier in Chrome macht initial den Button weiß und revert schminkt ihn wieder.
Rolf
--
sumpsi - posui - clusi-
hallo
Hallo beatovich,
gibt's nun auch eine Möglichkeit, wieder zum Browserdefault zurückzukehren? Zumindest hier in Chrome macht initial den Button weiß und revert schminkt ihn wieder.
wenn du mit Schminke pink meinst heisst das, dass Chrome revert nicht kennt.
-
@@Rolf B
gibt's nun auch eine Möglichkeit, wieder zum Browserdefault zurückzukehren?
Ja. Demnächst auch in Ihrem Browser.
Zumindest hier in Chrome macht initial den Button weiß und revert schminkt ihn wieder.
?? Bei in meinem Chrome sieht mein Pen so aus:
Ein Browser, der
background: revertnicht kennt, sollte die Deklaration ignorieren und das vorigebackground: initialsollte wirken.LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Hallo Gunnar,
ja eben. Weiß. Aber meine Default-Buttons sind grau.
Mal kurz den pen gespitzt:
<button>ungeschminkt</button> <button class="face">geschminkt</button> <button class="face abgeschminkt">abgeschminkt</button>button.face { background-color: pink; } button.ungeschminkt { background: initial; background: revert; }Rolf
--
sumpsi - posui - clusi-
@@Rolf B
ja eben. Weiß. Aber meine Default-Buttons sind grau.
Ja, eben. Genau das sagte Beat doch: „
initialrestauriert nicht den browser-Default.“reverttut das. Du musst nur abwarten …LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
-
-
-
-
-
-
-
@@1unitedpower
Ich wünschte du würdest Entwicklern ähnlich viel Empathie entgegen bringen wie du sie für Endnutzer aufbringst.
“In case of conflict, I will always value user needs above developer convenience. That’s called ‘work’.” —Jeremy Keith
Die Aussage unterschreibe ich sofort, sie passt hier aber nicht. Die Frage, die sich stellt, ist doch die: Hätte man Attribut-Selektoren so designen können, dass sie den Erwartungnen der Entwickler mehr entsprochen hätten? Hier gibt es also keinen Konflikt zwischen devloper convinience und user needs, nur schlechte developer convinience mit der wir jetzt Leben müssen.
Worüber aber am meisten gewettert wird, gehört nicht dazu: die Kaskade.
Dass die CSS-Denke anders ist als die Denke in Programmiersprachen, ist ein Feature, kein Bug.
Ehrlich gesagt tangiert mich die Kaskade nur peripher. Mit der Andersartigkeit von CSS habe ich auch kein Problem, domäne-spezifische Sprachen brauchen domäne-spezifische Features, um in ihrem Feld wirkungsvoll zu sein. Mich stören an CSS primär zwei Dinge: Das Mapping von Regeln auf DOM-Knoten: Gut finde ich, dass es rein deklarativ ist, schlecht finde ich, dass Selektoren nicht die DOM-Struktur reflektieren. Das Problem hat sich für mich mit CSS Modules aber gelöst. Die andere Sache ist, dass das CSS-Vokabular so enorm umfangreich ist, CSS setzt auf viele primitive Regeln anstatt auf wenige primtive Regeln und Komposition. Das ist sicher historisch bedingt und heute nur noch schwer zu überwinden, ich habe aber etwas Hoffnug in CSS Houdini.
-
-
-
-
-
-
-
-
Hi there,
Ganz ehrlich: Wenn du dich gerade einarbeitest, dann lerne JavaScript, nicht jQuery.
jQuery ist eine Bibliothek, die in der Vergangenheit einmal sehr nützlich war und die Weiterentwicklung von JavaScript beeinflusst hat und sich damit selbst überflüssig gemacht hat. Soll heißen: All die nützlichen Dinge von jQuery gibt es heute auch ohne jQuery, und das weitaus besser.
Ach Du meine Güte, daß ich Dir einmal recht geben darf...😉
-