nicht angemeldet
Linuchs
Gunnar Bittersmann
Linuchs
Rolf B
Auge
Auge
Rolf B
Linuchs
Matti Mäkitalo
Rolf B
Moin,
in einem Projekt kommen gleichartige Eingabefelder in mehreren Programmen vor.
Problem: Jedesmal habe ich Deepl bemüht, um die Bezeichnung mehrsprachig zu hinterlegen. Abgesehen vom Zeitaufwand war das nicht immer wortgleich.
Nun habe ich pro Eingabefeld eine Datei erstellt, die ich in der Platzhalter-Datei einfüge, vergleichbar mit PHP include. Also statt
Tabellenkalk
Matthias Scharwies
Der Martin<p><l>E-Mail <img id="email" class=help /></l>
<input required
type = 'text'
name = 'email'
title = 'email required'
maxlength = 100
value = '[email]'
> <i class="em08 chblau">5 .. 100</i></p>
sowas:
[feld_email_required]
Nun muss die Eingabe noch geprüft werden. Die PHP-function zum Prüfen hätte ich auch gerne in dieser Datei. Objektorientiert heißt ja, alles beisammen, was zum Objekt gehört.
function pruefeEmail( $email ) {
}
Gibt es da einen Standard? Oder wie löst ihr Eingabe und Prüfung objektorientiert? Habe eine Idee, aber Ich muss das Rad nicht neu erfinden
fragt Linuchs
@@Linuchs
Fehler: keine visuelle Zuordnung zwischen Beschriftung und Eingabefeld. Die Beschriftung sollte über dem Eingabefeld stehen, nicht irgendwo weit weg davon.
<p><l>E-Mail <img id="email" class=help /></l> <input required
Fehler: keine Zuordnung zwischen Beschriftung und Eingabefeld. Auf das label-Element wurdest du wiederholt hingewiesen.
<input required type = 'text' name = 'email'
Fehler: falscher type für das Eingabefeld.
Warum stellst du eigentlich immer neue Fragen, solange du die gegebenen Antworten ignorierst?
Und warum sollte man dir überhaupt noch antworten, wenn du die gegebenen Antworten ignorierst?
🖖 Живіть довго і процвітайте
Hallo Gunnar,
kaum bringt man eine Beispiel, schon wird die Frage übersehen und das Beispiel zerfleddert.
Die Beschriftung sollte über dem Eingabefeld stehen
Ist der Fall bei schmalen Viewports, beansprucht dreimal so viel Höhe wie bei stationären Displays.
Auf das label-Element wurdest du wiederholt hingewiesen.
Ich verwende es bei radio- und checkbuttons, da kann man auch auf den zugehörigen Text klicken. Lese nach, wozu das bei Textfeldern gut sein soll.
Das label-Attribut beschreibt den Text-Track.
Dafür habe ich meinen Infotext mit dem (i) Symbol, der online geändert werden kann und für alle gleichen Felder im Projekt gilt.
Aber mal sehen, was passiert, wenn ich das Beispiel einbaue ...
Nichts zu sehen, nichts zum Klicken.
Warum stellst du eigentlich immer neue Fragen, solange du die gegebenen Antworten ignorierst?
Manche Fragen gelten dem Hintergrund-Wissen und werden nicht 1:1 umgesetzt. Ich arbeite allein, so manche Lösung ist nicht Standard. Und was Standard sein soll, wird von verschiedenen Beteiligten unterschiedlich gesehen, oft wird eine Diskussion losgetreten. Nicht nur bei selfHTML
In diesem Faden frage ich nach Informationen, die zusammen stehen sollten. Ähnliche Diskussion hatten wir zu <style>, das bei selfHTML fern von der <form> definiert sein soll. Warum? Man kann es vor die Form setzen.
Und da ich ähnliche <form> für Mitglieder und Admins (mehr Felder) habe, macht das auch Sinn.
Gruß, Linuchs
Hallo Linuchs,
Das label-Attribut beschreibt den Text-Track.
Lies genau: Es geht um das label-Element, nicht ums Attribut. Dein erfundenes <l> Element möchte eigentlich ein label-Element sein und in seinem for-Attribut die ID des zugehörigen input-Elements vorweisen.
Das label-Attribut SOLLTE einen Effekt haben, wenn Du ein Medien-Element (audio oder video) hast und Untertitel oder Beschreibungen hinzufügst. Und zwar dort, wo man den gewünschten Text-Track auswählen kann. Ich habe das im Wiki aktualisiert.
Zu deiner OO Frage schreib ich noch was.
(...) <style> (...) Warum? Man kann es vor die Form setzen.
Das Thema <style> im <body> ist aus historischen Gründen erlaubt, aber nur dann, wenn das style-Element das scoped-Attribut besitzt. Denn nur dann handelt es sich um flow content, andernfalls ist <style> metadata content und gehört ausschließlich in den <head>. Die Browser interpretieren es im Body zwar und wenden die dort definierten style rules auch an - aber spezifiziert ist das nicht mehr. Der HTML 5 Spec-Entwurf von 2011 sah vor, dass ein <style scoped> nur innerhalb des Elternelements gelten soll, wo diese Styles stehen. Das passt zu Deinem Gebrauch nicht, bei Dir ist das Elternelement der Body.
Korrekt wäre, wenn Du den Seitenaufbau zweikanalig durchführst. Auf Kanal 1 baust Du den head auf, auf Kanal 2 den body, und dann, wenn alles fertig ist, gibst Du alles aus. Okay, Kanal 1 musst Du nicht buffern, den kannst Du sofort ausgeben, aber wenn Du Bausteine einbindest, die ihre Inhalte in head und body platzieren müssen, dann musst Du entweder zwei Durchgänge machen oder den body-Teil puffern, bis der head fertig ist. style-Elemente im body implizieren, dass alle Browser diesen unspezifizierten Teil von HTML unterstützen und sind deshalb nicht die Lösung, sondern ein Problem.
Insofern ist deine Verteidigungsrede leider nicht so ganz gelungen.
Rolf
Hallo,
Lies genau: Es geht um das label-Element, nicht ums Attribut.
Wer erfindet denn Elemente, die wie Attribute heißen, oder umgekehrt? Wieviele von der Sorte gibt es noch, und ist die Verwechslungsmöglichkeit im Wiki thematisiert?
Gruß
Kalk
@@Tabellenkalk
Wer erfindet denn Elemente, die wie Attribute heißen, oder umgekehrt? Wieviele von der Sorte gibt es noch …?
Ohne Anspruch auf Vollständigkeit:
citedata / data-*formlabelsource / srcstyletitle🖖 Живіть довго і процвітайте
Servus!
Hallo,
Lies genau: Es geht um das label-Element, nicht ums Attribut.
Wer erfindet denn Elemente, die wie Attribute heißen, oder umgekehrt?
Keine Ahnung, aber im Wiki gibt's so einige:
Spezial:Linkliste/Vorlage:Begriffsklärungshinweis
Wieviele von der Sorte gibt es noch, und ist die Verwechslungsmöglichkeit im Wiki thematisiert?
Irgendjemand hat's in die Beschreibung eingefügt. Ich habe den Satz/die Sätze mit einem Begriffsklärungshinweis vereinheitlicht.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
guck nochmal drauf; ich glaube, wir haben uns da einen kleinen Edit-War geliefert ohne es zu merken.
Rolf
Servus!
Hallo Matthias,
guck nochmal drauf; ich glaube, wir haben uns da einen kleinen Edit-War geliefert ohne es zu merken.
Finde ich nicht - schau mal in die Versionsgeschichte:
Was ich ganz peinlich finde: Eigentlich wollte ich die Vorlage:Begriffsklärungshinweis in die Vorlage:BK integrieren; die hat passend für's Makeover bereits eine role="navigation"- war mir aber schon nicht mehr erinnerlich 😉
Herzliche Grüße
Matthias Scharwies
Hallo
Hallo Gunnar,
kaum bringt man eine Beispiel, schon wird die Frage übersehen und das Beispiel zerfleddert.
Die Beschriftung sollte über dem Eingabefeld stehen
Ist der Fall bei schmalen Viewports, beansprucht dreimal so viel Höhe wie bei stationären Displays.
Auf das label-Element wurdest du wiederholt hingewiesen.
Ich verwende es bei radio- und checkbuttons, da kann man auch auf den zugehörigen Text klicken. Lese nach, wozu das bei Textfeldern gut sein soll.
Auch wenn dir das gewiss schon mehrere hundert Male geschrieben wurde, die durch die Beschriftung größere Klickfläche, die gerade bei Radiobuttons und Checkboxen hilfreich sind (nicht, dass sie es bei Texteingabefeldern nicht wären), sind nur eine Funktion. Die andere ist die Herstellung des Bezugs zwischen dem Eingabefeld und seiner Beschriftung. Dass bei dir die Beschriftung der Eingabefelder in deinem Fantasieelement l optisch vor den Eingabefeldern steht, ist nett. Dass die Beschriftung zu den jeweilig optisch folgenden Feldern gehört, ist nur aufgrund dieser Optik anzunehmen und bei möglicherweise schlecht gewählter HTML-Struktur nicht herzustellen, wenn man das Formular nicht sehen kann.
Die Beziehung zwischen Beschriftung eines Eingabefeldes und diesem selbst ist mit l jedenfalls nicht vorhanden. Mit label wäre sie es. Da du mit deiner Chorveranstaltungsseite ein mutmaßlich durchschnittlich eher gesetztes Publikum mit seiner üblicherweise zunehmend nachlassenden Sensorik ansprichst, solltest du es ihm nicht absichtlich schwer machen, deine Seite zu benutzen.
Hä? Auf welchem Wege landest du jetzt dort? Bis eben waren wir beim HTML-Element label. Wie kommst du jetzt zum gleichnamigen Attribut?
Dafür habe ich meinen Infotext mit dem (i) Symbol, der online geändert werden kann und für alle gleichen Felder im Projekt gilt.
Aber mal sehen, was passiert, wenn ich das Beispiel einbaue ...
Nichts zu sehen, nichts zum Klicken.
Welches Pferd?
Tschö, Auge
Hallo Auge,
Scrollen ist, wenn du es nicht aktiv verhinderst, möglich. Wenn du das für Mobilgeräte sowieso schon eingebaut hast, warum dann nicht auch für größere Viewports (die auf einem Desktop-Gerät sein können)? Scrollen ist auch dort möglich.
Ja und abends wirds dunkel. Was wolltest du mir mitteilen?
Die Beziehung zwischen Beschriftung eines Eingabefeldes und diesem selbst ist mit l jedenfalls nicht vorhanden. Mit label wäre sie es.
Das form, das ich gerade bearbeite, habe ich mit label angereichert. Also mein <l> durch <label> ersetzt bei gleichen DSS-Werten.
Was ich noch nie gesehen / ausprobiert (auch anderswo) habe, ist Klick auf den <label for>Bezeichner</label>. Der focussiert das Inputfeld. Darum geht es?
Was ich noch nie gesehen / ausprobiert (auch anderswo) habe, ist Klick auf den
<label for>Bezeichner</label>. Der focussiert das Inputfeld. Darum geht es?
Jein. Nicht nur. Das for=$IdDesInputs ist nur notwendig, wenn das Input-Element nicht umfasst wird:
Man kann also je nach Ansinnen:
<label>text
<input />
<label>
oder
<label for="id0815">text</label>
<input id="id0815" />
notieren. Trickreich: Man kann das eigentliche Formularelement (checkbox) sogar ganz verschwinden lassen und dennoch (ohne JS!) bedienen. Das mit dem „Focus on Click“ ist nicht die einzige Nettigkeit, sondern hilft auch Screenreadern und Programmen, die nur Text anzeigen.
Hallo Raketenwilli,
<label>text
<input />
<label>
sollte man vermeiden. Es gibt leider Screenreader, die daraus Murks machen. Sagt Gunnar.
Rolf
@@Rolf B
<label>text <input /> <label>sollte man vermeiden. Es gibt leider Screenreader, die daraus Murks machen. Sagt Gunnar.
Nö, Screenreader sind wohl nicht das Problem. Andere Software ist es.
🖖 Живіть довго і процвітайте
@@Raketenwilli
Das
for=$IdDesInputsist nur notwendig, wenn das Input-Element nicht umfasst wird:
Schön wär’s.
Es gibt aber Sorftware, die entgegen der HTML-Spec damit nicht klarkommt.
Auf der sicheren Seite ist man, wenn man auch bei Verschachtelung von input in label die Zuordnung mit id und for angibt.
Trickreich: Man kann das eigentliche Formularelement (checkbox) sogar ganz verschwinden lassen und dennoch (ohne JS!) bedienen.
Aber nur dann, wenn man sie visuell verschwinden lässt. Wenn man sie ganz verschwinden lässt (display: none oder sowas), wird sie unbenutzbar.
🖖 Живіть довго і процвітайте
Trickreich: Man kann das eigentliche Formularelement (checkbox) sogar ganz verschwinden lassen und dennoch (ohne JS!) bedienen.
Aber nur dann, wenn man sie visuell verschwinden lässt. Wenn man sie ganz verschwinden lässt (display: none oder sowas), wird sie unbenutzbar.
Wird gesendet, reagiert auf das change-event. Den Rest muss man aber scripten. Nicht, dass ich mir die Arbeit machen würde…
Hallo Raketenwilli,
wird aber von Assistenztechniken nicht mehr wahrgenommen. Für die ist das dann ein Label ohne belabeltes Dingsbums.
Rolf
Moin,
Für die ist das dann ein Label ohne belabeltes Dingsbums.
also quasi ein Dings ohne Bums. 😱
Einen schönen Tag noch
Martin
Hallo
Scrollen ist, wenn du es nicht aktiv verhinderst, möglich. Wenn du das für Mobilgeräte sowieso schon eingebaut hast, warum dann nicht auch für größere Viewports (die auf einem Desktop-Gerät sein können)? Scrollen ist auch dort möglich.
Ja und abends wirds dunkel. Was wolltest du mir mitteilen?
… dass dein Gegenargument, die Labels/Beschriftung oberhalb des Eingabefelds bräuchte vertikal dreimal soviel Platz, als wenn du sie neben den Feldern anzeigtes, keines ist. Im Browser ist quasi unendlich Platz.
Tschö, Auge
Hallo Linuchs,
[feld_email_required]
Wenn Du sowas bauen willst, dann sollte im Template sowas stehen wie [object:EMailRequired] und EMailRequired sollte der Name der Klasse sein, die das behandelt.
Wenn Du das Template interpretierst, dann findest Du ein object-Feld und weißt: Aha, ich muss ein Objekt der Klasse erzeugen, die hier angegeben ist.
Ich würde Dir empfehlen, diese Template-Klassen in einen PHP Namespace zu legen:
<?php
namespace FeldTemplate;
public class EMailRequired : AbstractTemplate
{
}
Damit ist sichergestellt, dass deine Templatenamen nicht mit anderen Klassen im System kollidieren.
Zurück zur Erzeugung. Du kannst einen generischen Autoloader für Klassen verwenden, der den Sourcecode der Klasse FeldTemplate\EMailRequired automatisch als EMailRequired.php im Ordner FeldTemplate sucht. Andernfalls machst Du das manuell, indem Du an der Stelle, wo Du das EMailRequired Template brauchst, den passenden require_once ausführst und danach das Objekt mit new erzeugst. Du kannst auch vorher mit class_exists abfragen, ob der require_once überhaupt nötig ist, aber ich glaube, das ist überflüssig.
Das so erstellte Objekt hat mehrere Aufgaben.
(1) Generieren des erforderlichen HTML für dieses UI Element (2) Durchführen der fachlichen Prüfungen beim Empfang von Daten für dieses UI Element.
Teil 1 ist relativ simpel, weil Du beim Erzeugen der HTML Seite genau weißt, dass ein [object:Foo] Feldmuster angefordert wurde. Da ist
$compName = "FieldTemplate\$template";
$component = new $compName();
$component->render();
Du wirst da sicher noch mehr Infos brauchen, bspw. braucht ein Eingabefeld auch einen Namen und einen Labeltext, die sollten im Template stehen.
[object:EMailRequired|name=email]
Auf diese Weise kannst Du deine Bausteine auch allgemeingültiger halten. Dass es eine requiredEmail ist, muss gar nicht ein spezielles Template bedeuten. Es kann auch ein generisches Makro für Eingabefelder sein:
[object:Textfeld|type=email|name=email|label=EMail-Adresse]
Da hast Du Freiraum zum Spielen, um eine für Dich brauchbare Vorgehensweise zu finden. Die Argumente hinter object:Textfeld sollte deine Template-Engine automatisch in ihre Teile zerlegen und der Klasse als Optionsarray bereitstellen.
Aber dann - wie transportiert man das zur Antwort. Letztlich musst Du für jedes so erzeugte Feld, das im Form ist, das Template-Objekt neu erzeugen, wenn der POST hereinkommt. D.h. Du musst wissen, welche Template-Objekte Du hast und wie sie erzeugt wurden.
Ein System wie ASP.NET macht sowas ähnliches; es liest die ASPX Seite vor dem Empfang eines POST erstmal wieder ein und baut das komplette Seitenobjektmodell neu auf. Und dieses Objektmodell konsumiert dann den POST Request. Aufwändig. Du könntest aber auch ein Array mit den Template-Informationen (also das [object:Textfeld|...] Geraffel) in ein Array schreiben, dieses Array serialisieren, irgendwie signieren (damit es Dir keiner fälscht), base64-codieren und als hidden input ins Form packen. Die Session ist dafür nicht unbedingt geeignet, das gibt Chaos falls ein User die Seite in zwei Browsertabs offen hat. Dann weißt Du beim POST, welche objektorientierten Bausteine drin sind.
Damit hast Du jetzt erstmal Stoff zum grübeln, denke ich. Selbst gebaut habe ich sowas noch nicht, aber so würde mein Konzept aussehen.
Rolf
Hallo Rolf,
Damit hast Du jetzt erstmal Stoff zum grübeln
Ich denke, das ist ein Studienfach und nicht „mal eben“ im Vorbeigehen gelernt.
Als Solist, also ohne Kollegen, habe ich mir ein Gerüst aufgebaut, das gut funktioniert aber offenbar nicht den westlichen Werten und Normen (CMS?) entspricht.
Hallo,
ich empfehle dir eine der vielen Form-Libraries zu nutzen. z.B. Symfony Forms
Viele Grüße Matti
Jetzt sag nicht, dass Du SOWAS willst:
<?php
class emailInput {
protected $id;
protected $adresse;
protected $name;
function __construct( $name, $adresse ) {
$this -> name = $name;
$this -> adresse = $adresse;
$this -> id = uniqid('I');
}
function printout() {
ob_start();
?>
<p><label for="<?=$this->id;?>" >E-Mail <img id="email" class=help /></label>
<input required
type = 'email'
name = 'email'
title = 'email required'
maxlength = 100
value = '<?=$this->adresse;?>'
> <i class="em08 chblau">5 .. 100</i></p>
<?php
echo preg_replace('/\s+/', ' ', ob_get_clean() );
}
}
?>
<h1>HTML-Geraffel</h1>
<?php $o=new emailInput('email', 'foo@example.org'); $o->printout();?>
Also funktionieren tut sowas. (Wie ein Test beweisen könnte.)
Hallo Raketenwilli,
da muss noch ein bisschen Framework drumherum, um die passende Klasse aus den Template-Dateien ableiten zu können.
Und das Rendering ist nur die halbe Miete. Wie Linuchs selbst schrub, ist das Empfangen und säuberliche Verarbeiten der Antwort genauso wichtig.
Seine Frage, wie "wir" das objektorientiert machen würden, werden die meisten vermutlich mit "gar nicht" beantworten. Oder wenn, dann mit einem fertigen Framework, so wie ich das mit ASP.NET Webforms gemacht habe. An der Stelle wäre sicher die Frage erlaubt, ob es ein vergleichbares Framework für PHP gibt, das auch noch unter PHP 5.6 läuft (aus Gründen...), denn dieses Rad ist zum Selbsterfinden ein bisschen schwergängig.
Rolf
(schon klar)
Dann kann er ja hier anfangen und sich überlegen,