Das sieht doch alles sehr abenteuerlich und unverstanden aus ;o)
Generell (kompatibel auch mit älteren Varianten von (X)HTML, steckt man Eingabefelder und Absendefelder oder -köpfe in ein gemeinsames form-Element als Vorfahre, wo man dann angibt, wohin man die Eingabe schicken will.
Neue Möglchkeit nach HTML5 ist, bei einem input-Element mit einem Attribut form anzugeben, zu welchem form-Element es gehört, welches man dann irgendwo beliebig im Dokument positionieren kann (nicht innerhalb von anderen form-Elementen allerdings).
Nachteilig dabei ist offenbar, daß es bei älteren Darstellungsprogrammen nicht funktionieren wird und der Nutzer meist nicht nachvollziehen können wird, welche Eingabe zu welchem Formular gehört, was er also in welchem Zusammenhang losschickt, in dem Sinne also eine von vielen eher zweifelhaften Neuerungen von HTML5.
Mit einem Element a schickt man ansonsten gar kein Formular los, wenn überhaupt, müßte man da die Formulardaten an die URI anhängen, dann kann der Nutzer sie aber nicht einfach ändern, nur wenn er die Adresse aus dem Queltext puhlt und selbst vor dem Absenden ändert.
Dies button-Element ergibt bei dir keinen Sinn, da kannst du das Aussehen des
Elementes a doch einfach mit CSS festlegen, brauchst dafür kein Element button mißbrauchen, was eben zu Formularen gehört, nicht zu normalen Verweisen.
Pfff. Nichtmal das Forum hier ist valide. Da mache ich mir ehrlich gesagt keinen Kopf drum.
Das stimmt.
Das sehe ich ein. Ich weiß nur eben nicht wie man so etwas bastelt. Und wenn ich tippe , dann sieht es genauso aus wie ich es haben möchte. Da war das nunmal sehr bequem.
[size=85]PS: Der Button soll ja nun genauso wie die anderen Standard-Buttons aussehen. Und da das ja vom Browser abhängt lag es nahe, eben auch diese Referenz wieder zu nehmen.[/size]
Ich bin aber offen für Vorschläge wie ich das geschickter machen kann.
Naja, es ist doch primär irritierend, etwas so aussehen zu lassen, als wäre es ein Formularelement, wenn es eben keines ist.
Ist fast so schlimm als ein Formular-Element für etwas anderes zu mißbrauchen ;o)
Mit CSS kann man ja alternative Ansichten für fast alles festlegen, auch für Formularelemente,
wenn man das für notwendig hält.
Rand oder Umrandung macht man mit border oder outline, eventuell dann noch ein padding spendieren.
Wenn du da etwas Sinnvolles zustande bringen willst, wird es sich jedenfalls nicht umgehen lassen, daß du mal in aller Ruhe eine Anleitung zu (X)HTML und CSS durchliest - und zwar komplett, nicht nur wahllos darin herumsuchen, was gerade ungefähr passen könnte ;o)
Ansonsten zu deinem CSS-Zeug: Die Einheit ‘vmin’ stammt aus einem Arbeitsentwurf zu einem Modul von CSS 3. das ist also keine offizielle Empfehlung, sollte man also nicht für öffentliche Seiten verwenden, solange das nicht eine Empfehlung ist, alleinfalls auf dem eigenen Rechner zum Testen. Angaben in Einheiten wie em oder ex zur Größe reichen vermutlich.
Auf den viewport bezogene Größen sind primär dann sehr hilfreich, wenn man Bilder oder Container für Bilder an den verfügbaren Anzeigebereich anpassen will, etwa in dem Sinne, daß ein Bild nicht größer ist als der zur Anzeige verfügbare Bildschirmbereich.
Von außen sieht ja keiner, ob der Button nun Formular oder nicht ist. Also wird da auch niemand verwirrt.
Und solange die Browser das vernünftig darstellen, soll es mir genügen. Es geht ohnehin nur um das Backend.
Eine “Anleitung zu (X)HTML und CSS” werde ich mir sicherlich nicht durchlesen können. Dazu ist das zu wenig mein Hobby und noch viel zu wenig mein Job. Das Ganze Projekt ist zudem so simpel, da wäre es wirklich übertrieben mehr zu machen. Jemand mit Erfahrung macht das vermutlich in 2 Stunden nebenbei. Und dann perfekt.
vmin gegen em tauschen? Mal sehen, ich guck mir das mal an.
Ich war nur begeistert, dass es eine Einheit relativ zur Größe des Viewpoints gibt. Das wäre für mich sehr hilfreich und auch generell finde ich das sinnvoll. Zudem unterstützen Firefox und Chrome (Desktop und Mobil) das, so dass ich mir einer weitgehenden Unterstützung sicher bin.
Sehr vielen Dank in jedem Fall für Deine Hinweise!
Nun, wenn es als Element button notiert ist, ist es auch ein solches.
Ob das Nutzer in einer visuellen Präsentation erkennen können, kann man als Autor nur begrenzt beeinflussen. Der Nutzer kann ja immer eine Präsentation gemäß der Funktion und Bedeutung favourisieren. Stilvorlagen des Autors sind da ja immer nur alternative Präsentationsvorschläge, die man nutzen kann oder auch nicht.
Es kommt also nur darauf an, als was es im Quelltext notiert ist, nicht darauf, wie ein Autor es präsentiert haben möchte.
Bei neuen CSS-Einheiten sollte man immer bedenken, daß ältere Programme die gewiß nicht kennen, aktuelle auch vermutlich nicht alle, eben weil es sich erst im Stadium eines Arbeitsentwurfes befindet, die Bedeutung oder Notation kann sich also noch beliebig ändern.
Nun ist es aber so, daß Programm, die die Einheit nicht kennen, die komplette Anweisung ignorieren, also so tun, als wäre das gar nicht notiert.
Da sollte man also das Verhalten testen, wenn gar nichts angegeben ist.
Die übliche Methode ist dann auch, zuvor eine Angabe mit alten Merkmalen zu machen, die dann von den neuen gegebenenfalls überschrieben werden.
Generell kann man es wohl als Fehler oder Mangel ansehen, wenn Darstellungsprogramme Merkmale aus Arbeitsentwürfen bereits im normalen Anzeigemodus interpretieren.
Eigentlich sollte das nur in einem speziellen Testmodus gehen.
Korrekt arbeitende Programme würden nicht standardisierte Merkmale folglich im normalen Betrieb nicht interpretieren.
Wobei man sagen muß, daß Mozilla/Gecko (Firefox Seamonkey etc) oder WebKit (Chromium, Safari, Goggle Chrome etc), MSIE etc natürlich leider viele Fehler haben.
Um die Aussagekraft einer Präsentation eines Projektes zu prüfen, sind die folglich nur in sehr begrenztem Umfange geeignet. Um zu prüfen, ob ein Projekt technisch korrekt und sinnvoll ist, sind sie praktisch komplett ungeeignet.
