info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
link als button innerhalb <form>?
1 view
Skip to first unread message
Ulli Horlacher
Jul 3, 2022, 3:39:55 AM7/3/22
to
Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
der wie ein button aussieht.
Mein erster naiver Ansatz:
<a href="/doit?parameter"><button>do something</button></a>
funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
google chrome). Ich brauch aber ein GET.
Ich hab jetzt:
[<a href="/doit?parameter">do something</a>]
Aber das ist optisch nicht das, was ich haben will.
Es sollte halt wie ein button aussehen (weil ausserhalb des <form> hab ich
welche).
Vorschlaege?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
der wie ein button aussieht.
Mein erster naiver Ansatz:
<a href="/doit?parameter"><button>do something</button></a>
funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
google chrome). Ich brauch aber ein GET.
Ich hab jetzt:
[<a href="/doit?parameter">do something</a>]
Aber das ist optisch nicht das, was ich haben will.
Es sollte halt wie ein button aussehen (weil ausserhalb des <form> hab ich
welche).
Vorschlaege?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Ulli Horlacher
Jul 3, 2022, 3:51:20 AM7/3/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
Zur Veranschaulichung:
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
https://fex.flupp.org/fop/j5wuyQhP/X-20220703094817.png
Zwischen den <hr> ist das <form> und ich moechte, dass [extract] wie
button aussieht.
Stefan Froehlich
Jul 3, 2022, 4:32:42 AM7/3/22
to
On Sun, 03 Jul 2022 09:39:53 Ulli Horlacher wrote:
> Ich hab ein <form> Formular und moechte da drin einen Link
> unterbringen, der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
> <a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest
> (zumindest bei google chrome). Ich brauch aber ein GET.
Gegen die Verwendung von <form method="get"> spricht vermutlich,
> Ich hab ein <form> Formular und moechte da drin einen Link
> unterbringen, der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
> <a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest
> (zumindest bei google chrome). Ich brauch aber ein GET.
dass Du auch noch andere Buttons hast, die POST verwenden sollen?
> Es sollte halt wie ein button aussehen (weil ausserhalb des <form>
> hab ich welche).
>
> Vorschlaege?
anders wird simulatanes GET/POST in einem Form nicht zu lösen sein,
und einen Textlink bekommst Du nicht (systemübergreifend) ident zu
einem Button gestyled.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Streicheln mit Stefan - arg werden mit Ironie.
(Sloganizer)
Ulli Horlacher
Jul 3, 2022, 4:48:53 AM7/3/22
to
Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> On Sun, 03 Jul 2022 09:39:53 Ulli Horlacher wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link
> > unterbringen, der wie ein button aussieht.
> >
> > Mein erster naiver Ansatz:
> >
> > <a href="/doit?parameter"><button>do something</button></a>
> >
> > funktioniert nicht, weil das dann ein HTTP POST ausloest
> > (zumindest bei google chrome). Ich brauch aber ein GET.
>
> Gegen die Verwendung von <form method="get"> spricht vermutlich,
> dass Du auch noch andere Buttons hast, die POST verwenden sollen?
>
> > Es sollte halt wie ein button aussehen (weil ausserhalb des <form>
> > hab ich welche).
> >
> > Vorschlaege?
>
> Sofern obiges zutrifft: JavaScript. Mag Dir nicht gefallen, aber
> anders wird simulatanes GET/POST in einem Form nicht zu lösen sein,
Doch! Das funktioniert innerhalb des <form>:
> On Sun, 03 Jul 2022 09:39:53 Ulli Horlacher wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link
> > unterbringen, der wie ein button aussieht.
> >
> > Mein erster naiver Ansatz:
> >
> > <a href="/doit?parameter"><button>do something</button></a>
> >
> > funktioniert nicht, weil das dann ein HTTP POST ausloest
> > (zumindest bei google chrome). Ich brauch aber ein GET.
>
> Gegen die Verwendung von <form method="get"> spricht vermutlich,
> dass Du auch noch andere Buttons hast, die POST verwenden sollen?
>
> > Es sollte halt wie ein button aussehen (weil ausserhalb des <form>
> > hab ich welche).
> >
> > Vorschlaege?
>
> Sofern obiges zutrifft: JavaScript. Mag Dir nicht gefallen, aber
> anders wird simulatanes GET/POST in einem Form nicht zu lösen sein,
<a href="/doit?parameter">do something</a>
Wie funktioniert dann ein button mit javascript?
Ulli Horlacher
Jul 3, 2022, 5:27:15 AM7/3/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> > der wie ein button aussieht.
>
> Zur Veranschaulichung:
>
> https://fex.flupp.org/fop/j5wuyQhP/X-20220703094817.png
>
> Zwischen den <hr> ist das <form> und ich moechte, dass [extract] wie
> button aussieht.
Hab eine Loesung gefunden!
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> > der wie ein button aussieht.
>
> Zur Veranschaulichung:
>
> https://fex.flupp.org/fop/j5wuyQhP/X-20220703094817.png
>
> Zwischen den <hr> ist das <form> und ich moechte, dass [extract] wie
> button aussieht.
<style>
.button {
font: bold 11px Arial;
text-decoration: none;
background-color: #EEEEEE;
color: #333333;
padding: 2px 6px 2px 6px;
border: 1px solid black;
}
</style>
(...)
<a class="button" href="$uf?ACTION=extract">extract</a>
Sieht nun so aus:
https://fex.flupp.org/fop/ypZ8MhNB/X-20220703111813.png
Stefan Froehlich
Jul 3, 2022, 7:41:47 AM7/3/22
to
On Sun, 03 Jul 2022 10:48:51 Ulli Horlacher wrote:
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> Gegen die Verwendung von <form method="get"> spricht vermutlich,
>> dass Du auch noch andere Buttons hast, die POST verwenden sollen?
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> Gegen die Verwendung von <form method="get"> spricht vermutlich,
>> dass Du auch noch andere Buttons hast, die POST verwenden sollen?
>> Sofern obiges zutrifft: JavaScript. Mag Dir nicht gefallen, aber
>> anders wird simulatanes GET/POST in einem Form nicht zu lösen
>> sein,
> Doch! Das funktioniert innerhalb des <form>:
>
> <a href="/doit?parameter">do something</a>
Ich meinte ob des Kontexts schon: simultanes GET/POST mit Buttons.
>> anders wird simulatanes GET/POST in einem Form nicht zu lösen
>> sein,
> Doch! Das funktioniert innerhalb des <form>:
>
> <a href="/doit?parameter">do something</a>
> Erst wenn ich <button> einfuege, gehts nicht mehr.
> Wie funktioniert dann ein button mit javascript?
ersetzen. Schön ist IMO anders.
Wenn Dir das im anderen Posting gezeigte CSS reicht, dann bleib'
dabei. Das Problem damit ist halt, dass es nur das Design *deines*
Browsers imitiert.
(Als Benutzer empfinde ich solche Umgestaltungen immer ambivalent:
Die Unterscheidung von Link und Button gibt mir ja auch
Informationen bezüglich dessen, was im Hintergrund passieren kann
oder auch nicht).
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Stefan Froehlich
Jul 3, 2022, 7:45:10 AM7/3/22
to
On Sun, 03 Jul 2022 13:41:45 Stefan Froehlich wrote:
> (Als Benutzer empfinde ich solche Umgestaltungen immer ambivalent:
> Die Unterscheidung von Link und Button gibt mir ja auch
> Informationen bezüglich dessen, was im Hintergrund passieren kann
> oder auch nicht).
Ich habe mir erst jetzt Deine Screenshots angesehen :-)
> (Als Benutzer empfinde ich solche Umgestaltungen immer ambivalent:
> Die Unterscheidung von Link und Button gibt mir ja auch
> Informationen bezüglich dessen, was im Hintergrund passieren kann
> oder auch nicht).
Was spricht bei "extract" eigentlich *gegen* einen POST-Request?
Es werden Daten verändert, und sinnvollerweise sollte der Aufruf
auch nicht ohne Rückfrage wiederholt werden, oder?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 3, 2022, 7:57:15 AM7/3/22
to
Ulli Horlacher:
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
> <a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> google chrome). Ich brauch aber ein GET.
Logisch, weil <button> eben ein eigenes Element ist.
> Ich hab jetzt:
>
> [<a href="/doit?parameter">do something</a>]
>
> Aber das ist optisch nicht das, was ich haben will.
Dann musst Du eben mit CSS etwas bauen, was wie ein Button aussieht und
das dann als Klasse im <a> angeben.
Sinnvollerweise verwendet man die selbe CSS-Klasse auch für echte
Buttons, damit das einheitlich ist.
Also z.B. so:
<style>
.button, button, input[type="submit"], input[type="button"] {
padding: 0.5em;
border: 1px solid #000;
border-radius: 0.25em;
}
</style>
<a class="button" href="/doit?parameter">do something</a>
Ja, die genaue Optik müsste man evtl. noch anpassen. Oder man nimmt
gleich CSS-Frameworks wie Bootstrap, da ist das alles schon dabei.
--
Arno Welzel
https://arnowelzel.de
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
> <a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> google chrome). Ich brauch aber ein GET.
> Ich hab jetzt:
>
> [<a href="/doit?parameter">do something</a>]
>
> Aber das ist optisch nicht das, was ich haben will.
das dann als Klasse im <a> angeben.
Sinnvollerweise verwendet man die selbe CSS-Klasse auch für echte
Buttons, damit das einheitlich ist.
Also z.B. so:
<style>
.button, button, input[type="submit"], input[type="button"] {
padding: 0.5em;
border: 1px solid #000;
border-radius: 0.25em;
}
</style>
<a class="button" href="/doit?parameter">do something</a>
Ja, die genaue Optik müsste man evtl. noch anpassen. Oder man nimmt
gleich CSS-Frameworks wie Bootstrap, da ist das alles schon dabei.
--
Arno Welzel
https://arnowelzel.de
Ulli Horlacher
Jul 3, 2022, 2:52:43 PM7/3/22
to
Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> On Sun, 03 Jul 2022 13:41:45 Stefan Froehlich wrote:
> > (Als Benutzer empfinde ich solche Umgestaltungen immer ambivalent:
> > Die Unterscheidung von Link und Button gibt mir ja auch
> > Informationen bezüglich dessen, was im Hintergrund passieren kann
> > oder auch nicht).
>
> Ich habe mir erst jetzt Deine Screenshots angesehen :-)
>
> Was spricht bei "extract" eigentlich *gegen* einen POST-Request?
Es waeren 2 Aktionen:
> On Sun, 03 Jul 2022 13:41:45 Stefan Froehlich wrote:
> > (Als Benutzer empfinde ich solche Umgestaltungen immer ambivalent:
> > Die Unterscheidung von Link und Button gibt mir ja auch
> > Informationen bezüglich dessen, was im Hintergrund passieren kann
> > oder auch nicht).
>
> Ich habe mir erst jetzt Deine Screenshots angesehen :-)
>
> Was spricht bei "extract" eigentlich *gegen* einen POST-Request?
1) Select-Box anwaehlen
2) [submit] anklicken
Damit sind meine User ueberfordert.
Arno Welzel
Jul 4, 2022, 4:05:32 AM7/4/22
to
Ulli Horlacher:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
>>> der wie ein button aussieht.
>>
>> Zur Veranschaulichung:
>>
>> https://fex.flupp.org/fop/j5wuyQhP/X-20220703094817.png
>>
>> Zwischen den <hr> ist das <form> und ich moechte, dass [extract] wie
>> button aussieht.
>
> Hab eine Loesung gefunden!
>
> <style>
> .button {
> font: bold 11px Arial;
> text-decoration: none;
> background-color: #EEEEEE;
> color: #333333;
> padding: 2px 6px 2px 6px;
> border: 1px solid black;
> }
> </style>
> (...)
> <a class="button" href="$uf?ACTION=extract">extract</a>
Problem: ob echte Buttons auch genau so aussehen, ist keinesfalls
garantiert - das hängt vom Browser ab.
Du solltest daher die CSS-Regel erweitern, dass sie auch für echte
Buttons gilt, damit diese garantiert identisch aussehen:
<style>
.button, button, input[type="button"], input[type="submit"] {
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
>>> der wie ein button aussieht.
>>
>> Zur Veranschaulichung:
>>
>> https://fex.flupp.org/fop/j5wuyQhP/X-20220703094817.png
>>
>> Zwischen den <hr> ist das <form> und ich moechte, dass [extract] wie
>> button aussieht.
>
> Hab eine Loesung gefunden!
>
> <style>
> .button {
> font: bold 11px Arial;
> text-decoration: none;
> background-color: #EEEEEE;
> color: #333333;
> padding: 2px 6px 2px 6px;
> border: 1px solid black;
> }
> </style>
> (...)
> <a class="button" href="$uf?ACTION=extract">extract</a>
garantiert - das hängt vom Browser ab.
Du solltest daher die CSS-Regel erweitern, dass sie auch für echte
Buttons gilt, damit diese garantiert identisch aussehen:
<style>
.button, button, input[type="button"], input[type="submit"] {
Peter J. Holzer
Jul 7, 2022, 10:01:20 AM7/7/22
to
On 2022-07-03 07:39, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
><a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> google chrome). Ich brauch aber ein GET.
<button formmethod="GET">
> Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> der wie ein button aussieht.
>
> Mein erster naiver Ansatz:
>
><a href="/doit?parameter"><button>do something</button></a>
>
> funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> google chrome). Ich brauch aber ein GET.
Du kannst auch mit formaction den URL ändern.
Oder mit type="button" einen Button ohne default-Action erzeugen. Dann
funktioniert das mit dem <a> rundherum.
Siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button
hp
PS: Ich würds wahrscheinlich auch mit CSS machen, aber button hat einige
recht praktische Attribute. Es zahlt sich aus, hin und wieder Doku zu
lesen - HTML ändert sich und es kommt immer wieder mal was neues dazu.
Ulli Horlacher
Jul 7, 2022, 10:59:26 AM7/7/22
to
Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2022-07-03 07:39, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> > der wie ein button aussieht.
> >
> > Mein erster naiver Ansatz:
> >
> ><a href="/doit?parameter"><button>do something</button></a>
> >
> > funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> > google chrome). Ich brauch aber ein GET.
>
> <button formmethod="GET">
>
> Du kannst auch mit formaction den URL ändern.
>
> Oder mit type="button" einen Button ohne default-Action erzeugen. Dann
> funktioniert das mit dem <a> rundherum.
>
> Siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button
Ohh... SO einfach!
> On 2022-07-03 07:39, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Ich hab ein <form> Formular und moechte da drin einen Link unterbringen,
> > der wie ein button aussieht.
> >
> > Mein erster naiver Ansatz:
> >
> ><a href="/doit?parameter"><button>do something</button></a>
> >
> > funktioniert nicht, weil das dann ein HTTP POST ausloest (zumindest bei
> > google chrome). Ich brauch aber ein GET.
>
> <button formmethod="GET">
>
> Du kannst auch mit formaction den URL ändern.
>
> Oder mit type="button" einen Button ohne default-Action erzeugen. Dann
> funktioniert das mit dem <a> rundherum.
>
> Siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button
> PS: Ich würds wahrscheinlich auch mit CSS machen, aber button hat einige
> recht praktische Attribute. Es zahlt sich aus, hin und wieder Doku zu
> lesen - HTML ändert sich und es kommt immer wieder mal was neues dazu.
Ich belass es aber nun mit CSS (Wie von Arno vorgeschlagen), das gefaellt
mir besser:
https://fex.rus.uni-stuttgart.de/fop/Wn2Wjits/X-20220707165531.png
[list] ist mit <button type="button">
[extract] ist mit <a class="button">
Stefan Froehlich
Jul 7, 2022, 11:20:29 AM7/7/22
to
On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
> und es kommt immer wieder mal was neues dazu.
Das ist das Schöne an einem "living standard", man weiss irgendwie
> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
> und es kommt immer wieder mal was neues dazu.
nie, woran man gerade ist und was sich seit dem letzten Mal alles
verändert hat :-(
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 9, 2022, 11:06:04 PM7/9/22
to
Stefan Froehlich:
> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>> und es kommt immer wieder mal was neues dazu.
>
> Das ist das Schöne an einem "living standard", man weiss irgendwie
> nie, woran man gerade ist und was sich seit dem letzten Mal alles
> verändert hat :-(
Die beschriebenen Optionen gibt es seit über 10 Jahren:
<https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#the-button-element>
Quelle - "W3C Working Draft 25 May 2011":
<https://www.w3.org/TR/2011/WD-html5-20110525/>
> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>> und es kommt immer wieder mal was neues dazu.
>
> Das ist das Schöne an einem "living standard", man weiss irgendwie
> nie, woran man gerade ist und was sich seit dem letzten Mal alles
> verändert hat :-(
<https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#the-button-element>
Quelle - "W3C Working Draft 25 May 2011":
<https://www.w3.org/TR/2011/WD-html5-20110525/>
Stefan Froehlich
Jul 10, 2022, 5:34:53 AM7/10/22
to
On Sun, 10 Jul 2022 05:06:03 Arno Welzel wrote:
> Stefan Froehlich:
>> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>>> und es kommt immer wieder mal was neues dazu.
>>
>> Das ist das Schöne an einem "living standard", man weiss irgendwie
>> nie, woran man gerade ist und was sich seit dem letzten Mal alles
>> verändert hat :-(
>
> Die beschriebenen Optionen gibt es seit über 10 Jahren: [...]
> Stefan Froehlich:
>> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>>> und es kommt immer wieder mal was neues dazu.
>>
>> Das ist das Schöne an einem "living standard", man weiss irgendwie
>> nie, woran man gerade ist und was sich seit dem letzten Mal alles
>> verändert hat :-(
>
Das war jetzt eher ein grundsätzlicher Rant; es kann jederzeit etwas
sinn(voll|los)es dazukommen, ohne dass es irgendwie großartig
auffällt.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 10, 2022, 6:36:26 AM7/10/22
to
Stefan Froehlich:
> On Sun, 10 Jul 2022 05:06:03 Arno Welzel wrote:
>> Stefan Froehlich:
>>> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>>>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>>>> und es kommt immer wieder mal was neues dazu.
>>>
>>> Das ist das Schöne an einem "living standard", man weiss irgendwie
>>> nie, woran man gerade ist und was sich seit dem letzten Mal alles
>>> verändert hat :-(
>>
>> Die beschriebenen Optionen gibt es seit über 10 Jahren: [...]
>
> Das war jetzt eher ein grundsätzlicher Rant; es kann jederzeit etwas
> sinn(voll|los)es dazukommen, ohne dass es irgendwie großartig
> auffällt.
Er passt halt nur zu diesem konkreten Fall gar nicht.
CSS kannte noch nie Versionsnummern und die Leute hatten damit auch kein
Problem, dass mit CSS2 und 3 Dinge dazugekommen sind, die nach und nach
von allen Browsern unterstützt wurden.
Weiterhin hilft es ja nicht, wenn HTML5 eine Versionsnummer mit
definiertem Standard pro Version hätte - Browser müssen diese Version ja
auch unterstützen, was erfahrungsgemäß immer einige Zeit dauert. Dann
kannst Du zwar dein Dokument entsprechend kennzeichnen, aber die
verwendeten Elemente funktionieren trotzdem nicht so wie erwartet.
> On Sun, 10 Jul 2022 05:06:03 Arno Welzel wrote:
>> Stefan Froehlich:
>>> On Thu, 07 Jul 2022 16:01:18 Peter J. Holzer wrote:
>>>> Es zahlt sich aus, hin und wieder Doku zu lesen - HTML ändert sich
>>>> und es kommt immer wieder mal was neues dazu.
>>>
>>> Das ist das Schöne an einem "living standard", man weiss irgendwie
>>> nie, woran man gerade ist und was sich seit dem letzten Mal alles
>>> verändert hat :-(
>>
>> Die beschriebenen Optionen gibt es seit über 10 Jahren: [...]
>
> Das war jetzt eher ein grundsätzlicher Rant; es kann jederzeit etwas
> sinn(voll|los)es dazukommen, ohne dass es irgendwie großartig
> auffällt.
CSS kannte noch nie Versionsnummern und die Leute hatten damit auch kein
Problem, dass mit CSS2 und 3 Dinge dazugekommen sind, die nach und nach
von allen Browsern unterstützt wurden.
Weiterhin hilft es ja nicht, wenn HTML5 eine Versionsnummer mit
definiertem Standard pro Version hätte - Browser müssen diese Version ja
auch unterstützen, was erfahrungsgemäß immer einige Zeit dauert. Dann
kannst Du zwar dein Dokument entsprechend kennzeichnen, aber die
verwendeten Elemente funktionieren trotzdem nicht so wie erwartet.
Arno Welzel
Jul 10, 2022, 7:27:27 AM7/10/22
to
Arno Welzel:
Ergänzend:
Als HTML5 verabschiedet wurde, war der größte Teil dessen, was noch
heute so gilt, bereits definiert.
Man aber auch reinschauen in die Spezifikation. Mir war auch nicht
bewusst, dass <button> inklusive der Angaben wie "formaction" oder
"formmethod" bereits zur Einführung von HTML5 genau so definiert wurde,
weil mich das bisher nie interessiert hat. Sich da nun zu beklagen, dass
man das wegen "living standard" nicht wüsste, passt aber dann nicht.
Tatsächlich hätte man einfach nur die seit über 10 Jahren existierende
Spezifikation von HTML5 begutachten müssen.
Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch ein
Changelog gäbe, damit man zumindest weiß, ob sich gegenüber dem Stand,
den man kennt, etwas grundlegenderes geändert hat. Zumindest
Browserhersteller müssen die Änderungen ja auch explizit
berücksichtigen, daher bin ich auch etwas erstaunt, dass es offenbar
nichts offizielles dazu in Form eines Dokumentes gibt.
Die einzigen Quellen dazu sind in
<https://github.com/whatwg/html/blob/main/FAQ.md> dokumentiert:
Twitter: <https://twitter.com/htmlstandard>
Commit log in Github: <https://github.com/whatwg/html/commits>
Als HTML5 verabschiedet wurde, war der größte Teil dessen, was noch
heute so gilt, bereits definiert.
Man aber auch reinschauen in die Spezifikation. Mir war auch nicht
bewusst, dass <button> inklusive der Angaben wie "formaction" oder
"formmethod" bereits zur Einführung von HTML5 genau so definiert wurde,
weil mich das bisher nie interessiert hat. Sich da nun zu beklagen, dass
man das wegen "living standard" nicht wüsste, passt aber dann nicht.
Tatsächlich hätte man einfach nur die seit über 10 Jahren existierende
Spezifikation von HTML5 begutachten müssen.
Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch ein
Changelog gäbe, damit man zumindest weiß, ob sich gegenüber dem Stand,
den man kennt, etwas grundlegenderes geändert hat. Zumindest
Browserhersteller müssen die Änderungen ja auch explizit
berücksichtigen, daher bin ich auch etwas erstaunt, dass es offenbar
nichts offizielles dazu in Form eines Dokumentes gibt.
Die einzigen Quellen dazu sind in
<https://github.com/whatwg/html/blob/main/FAQ.md> dokumentiert:
Twitter: <https://twitter.com/htmlstandard>
Commit log in Github: <https://github.com/whatwg/html/commits>
Stefan Froehlich
Jul 10, 2022, 1:42:36 PM7/10/22
to
On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
> Arno Welzel:
>> Stefan Froehlich:
>>> On Sun, 10 Jul 2022 05:06:03 Arno Welzel wrote:
>>>> Stefan Froehlich:
> Arno Welzel:
>> Stefan Froehlich:
>>> On Sun, 10 Jul 2022 05:06:03 Arno Welzel wrote:
>>>> Stefan Froehlich:
>>>>> Das ist das Schöne an einem "living standard", man weiss
>>>>> irgendwie nie, woran man gerade ist und was sich seit dem
>>>>> letzten Mal alles verändert hat :-(
>>>>> irgendwie nie, woran man gerade ist und was sich seit dem
>>>>> letzten Mal alles verändert hat :-(
>>> Das war jetzt eher ein grundsätzlicher Rant; es kann jederzeit
>>> etwas sinn(voll|los)es dazukommen, ohne dass es irgendwie
>>> großartig auffällt.
>> Er passt halt nur zu diesem konkreten Fall gar nicht.
So viel Traffic ist hier halt nicht.
>>> etwas sinn(voll|los)es dazukommen, ohne dass es irgendwie
>>> großartig auffällt.
>> Er passt halt nur zu diesem konkreten Fall gar nicht.
>> CSS kannte noch nie Versionsnummern und die Leute hatten damit
>> auch kein Problem, dass mit CSS2 und 3 Dinge dazugekommen sind,
>> die nach und nach von allen Browsern unterstützt wurden.
höre ich diese Kritik ja auch nur sehr selten, dennoch bin *ich* der
Meinung, dass die Vorgehensweise ein Unding ist.
>> Weiterhin hilft es ja nicht, wenn HTML5 eine Versionsnummer mit
>> definiertem Standard pro Version hätte - Browser müssen diese
>> Version ja auch unterstützen, was erfahrungsgemäß immer einige
>> Zeit dauert.
Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
natürlich einfacher, wenn man weiss: HTML 5.xy ist im September 2015
veröffentlicht worden, also sehe ich mir das ab kommendem Jahr
langsam einmal an und überlege mir, ob und wo es mir etwas bringen
könnte.
> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
alle paar Jahre den Standard von vorne bis hinten durchlesen, um -
mit etwas Glück - auf Änderungen zu stoßen. Das ist natürlich völlig
unpraktikabel, und so ändere ich in letzter Zeit eigentlich so gut
wie gar nichts mehr, ausser ich stolpere per Zufall darüber.
Das stört in der Praxis zwar erstaunlich wenig, ist aber doch
irgendwo auch schade.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 10, 2022, 3:16:45 PM7/10/22
to
Stefan Froehlich:
> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>> Arno Welzel:
[...]
> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>> Arno Welzel:
>>> Weiterhin hilft es ja nicht, wenn HTML5 eine Versionsnummer mit
>>> definiertem Standard pro Version hätte - Browser müssen diese
>>> Version ja auch unterstützen, was erfahrungsgemäß immer einige
>>> Zeit dauert.
>
> Natürlich - das Problem war auch schon früher existent und ist per
> Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September 2015
> veröffentlicht worden, also sehe ich mir das ab kommendem Jahr
> langsam einmal an und überlege mir, ob und wo es mir etwas bringen
> könnte.
Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre ich
>>> definiertem Standard pro Version hätte - Browser müssen diese
>>> Version ja auch unterstützen, was erfahrungsgemäß immer einige
>>> Zeit dauert.
>
> Natürlich - das Problem war auch schon früher existent und ist per
> Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September 2015
> veröffentlicht worden, also sehe ich mir das ab kommendem Jahr
> langsam einmal an und überlege mir, ob und wo es mir etwas bringen
> könnte.
arbeitslos. HTML5 nutze ich in der täglichen Praxis schon seit 8 Jahren
und HTML 4.01 ist im Vergleich dazu gruselig.
XHTML 1.0 war zwar zumindest "well-formed" und konnte weiterhin als HTML
ausgeliefert werden, brachte sonst aber wenig Vorteile.
XHTML 1.1 wiederum war zwar erweiterbar, sollte aber als
"application/xhtml+xml" ausgeliefert werden was wiederum mit älteren
Browsern massive Probleme gemacht hat.
>> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
>> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
>> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
>
> Das ist mein Hauptproblem damit. Im Grund genommen müsste ich mir
> alle paar Jahre den Standard von vorne bis hinten durchlesen, um -
> mit etwas Glück - auf Änderungen zu stoßen. Das ist natürlich völlig
> unpraktikabel, und so ändere ich in letzter Zeit eigentlich so gut
> wie gar nichts mehr, ausser ich stolpere per Zufall darüber.
neben Validatoren ggf. Quellen wie <https://caniuse.com> oder
<http://html5doctor.com> konsultieren. Nur darüber nachdenken, ob HTML5
nun nach mittlerweile fast 10 Jahren nach Veröffentlichung der ersten
vollständigen Version irgendwas bringt, wird Dich diesbezüglich nicht
weiterbringen.
Stefan Froehlich
Jul 11, 2022, 4:23:38 AM7/11/22
to
On Sun, 10 Jul 2022 21:16:45 Arno Welzel wrote:
> Stefan Froehlich:
> Stefan Froehlich:
>> Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
>> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
>> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September
>> 2015 veröffentlicht worden, also sehe ich mir das ab kommendem
>> Jahr langsam einmal an und überlege mir, ob und wo es mir etwas
>> bringen könnte.
> Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre
> ich arbeitslos.
Das geht mir ähnlich, und auch wenn sich mein voriges Posting für
>> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
>> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September
>> 2015 veröffentlicht worden, also sehe ich mir das ab kommendem
>> Jahr langsam einmal an und überlege mir, ob und wo es mir etwas
>> bringen könnte.
> Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre
> ich arbeitslos.
Dich eher gruselig lesen mag, lebe ich damit noch immer nicht
risikolos. Beim Umstieg auf HTML5 zum Jahreswechsel 2017/18 habe ich
mir tatsächlich (und unerwartet) ganz massive Probleme bei einem
Kunden eingefangen, der damit schlichtweg nicht arbeiten konnte -
für den wurde dann weitere zwei Jahre eine alte Version mitgeführt,
was auf meiner Seite erheblichen Aufwand bedeutet hat.
Die Welt von hippen Endkunden sieht deutlich anders aus, als die von
altehrwürdigen Dienstleistungsbetrieben.
> HTML5 nutze ich in der täglichen Praxis schon seit 8 Jahren und
> HTML 4.01 ist im Vergleich dazu gruselig.
mich als um diejenigen, die mit dem Produkt dann arbeiten (müssen).
> Nur darüber nachdenken, ob HTML5 nun nach mittlerweile fast 10
> Jahren nach Veröffentlichung der ersten vollständigen Version
> irgendwas bringt, wird Dich diesbezüglich nicht weiterbringen.
vergangen, und meine Motivation, mir mit relativ viel Mühe das Delta
seit damals anzueignen, hält sich in sehr überschaubaren Grenzen.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 11, 2022, 5:03:57 AM7/11/22
to
Stefan Froehlich:
> On Sun, 10 Jul 2022 21:16:45 Arno Welzel wrote:
>> Stefan Froehlich:
>>> Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
>>> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
>>> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September
>>> 2015 veröffentlicht worden, also sehe ich mir das ab kommendem
>>> Jahr langsam einmal an und überlege mir, ob und wo es mir etwas
>>> bringen könnte.
>
>> Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre
>> ich arbeitslos.
>
> Das geht mir ähnlich, und auch wenn sich mein voriges Posting für
> Dich eher gruselig lesen mag, lebe ich damit noch immer nicht
> risikolos. Beim Umstieg auf HTML5 zum Jahreswechsel 2017/18 habe ich
> mir tatsächlich (und unerwartet) ganz massive Probleme bei einem
> Kunden eingefangen, der damit schlichtweg nicht arbeiten konnte -
> für den wurde dann weitere zwei Jahre eine alte Version mitgeführt,
> was auf meiner Seite erheblichen Aufwand bedeutet hat.
Lass mich raten: Internet Explorer 10 oder älter? Sonst fällt mir kein
Grund ein, HTML5 nicht zu verwenden. Aber selbst da konnte man mit
html5shiv noch etliche Probleme beheben - habe ich selbst in den
Anfangsjahren noch gemacht.
Aber zur Einordnung: Internet Explorer 11, mit dem HTML5 schon recht
problemlos möglich ist, wurde bereits 2013 veröffentlicht und war damit
2017 schon wenigstens 4 Jahre alt. Mittlerweile ist der Support für
manche Windows-Versionen auch schon abgelaufen
(<https://docs.microsoft.com/de-de/lifecycle/announcements/internet-explorer-11-end-of-support>).
Ja, wenn man unbedingt solche Kunden bedienen muss, muss man wohl
Kompromisse eingehen. Dann würde ich die Kosten aber auch entsprechend
ansetzen - der Kunde soll schon merken, dass Festhalten an veralteter
Technik teuer sein kann, sonst tut sich da nichts und man muss auch im
Jahr 2023 noch Windows 7 und IE 10 berücksichtigen.
> Die Welt von hippen Endkunden sieht deutlich anders aus, als die von
> altehrwürdigen Dienstleistungsbetrieben.
Ich rede davon, dass *heute* HTML5 Standard ist. Aber auch 2017/18 war
das schon so.
Ja, ich habe auch mit "altehrwürdigen Dienstleistungsbetrieben" zu tun.
Nicht alle sind so drauf, dass dort noch Internet Explorer 8 oder
Uralt-Versionen von Safari das Maß der Dinge ist. HTML5 und Bootstrap
funktioniert da in der Regel problemlos.
Auch in der Welt der "altehrwürdigen Dienstleistungsbetriebe" muss man
spätestens bei Abkündigung von Software (Windows 7, Internet Explorer
etc.) den Schritt gehen, auf eine noch gewartete Version umzustellen,
wenn man keine Sicherheitsprobleme riskieren will.
[...]
so, dass alle paar Monate grundlegende Dinge geändert werden.
Schließlich muss die Browser-Entwicklung auch mithalten.
Siehe die Diskussion um das <button>-Element - alle genannten Attribute
wie "formmethod" oder "formaction" wie wurden bereits von Anfang an
genau so eingeführt und nicht erst in den letzten Jahren hinzugefügt.
> On Sun, 10 Jul 2022 21:16:45 Arno Welzel wrote:
>> Stefan Froehlich:
>>> Definition nur schwer lösbar. Ich habe daher immer knapp 10 Jahre
>>> Abstand zu aktuellen Entwicklungen gehalten; aber auch das ist
>>> natürlich einfacher, wenn man weiss: HTML 5.xy ist im September
>>> 2015 veröffentlicht worden, also sehe ich mir das ab kommendem
>>> Jahr langsam einmal an und überlege mir, ob und wo es mir etwas
>>> bringen könnte.
>
>> Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre
>> ich arbeitslos.
>
> Das geht mir ähnlich, und auch wenn sich mein voriges Posting für
> Dich eher gruselig lesen mag, lebe ich damit noch immer nicht
> risikolos. Beim Umstieg auf HTML5 zum Jahreswechsel 2017/18 habe ich
> mir tatsächlich (und unerwartet) ganz massive Probleme bei einem
> Kunden eingefangen, der damit schlichtweg nicht arbeiten konnte -
> für den wurde dann weitere zwei Jahre eine alte Version mitgeführt,
> was auf meiner Seite erheblichen Aufwand bedeutet hat.
Grund ein, HTML5 nicht zu verwenden. Aber selbst da konnte man mit
html5shiv noch etliche Probleme beheben - habe ich selbst in den
Anfangsjahren noch gemacht.
Aber zur Einordnung: Internet Explorer 11, mit dem HTML5 schon recht
problemlos möglich ist, wurde bereits 2013 veröffentlicht und war damit
2017 schon wenigstens 4 Jahre alt. Mittlerweile ist der Support für
manche Windows-Versionen auch schon abgelaufen
(<https://docs.microsoft.com/de-de/lifecycle/announcements/internet-explorer-11-end-of-support>).
Ja, wenn man unbedingt solche Kunden bedienen muss, muss man wohl
Kompromisse eingehen. Dann würde ich die Kosten aber auch entsprechend
ansetzen - der Kunde soll schon merken, dass Festhalten an veralteter
Technik teuer sein kann, sonst tut sich da nichts und man muss auch im
Jahr 2023 noch Windows 7 und IE 10 berücksichtigen.
> Die Welt von hippen Endkunden sieht deutlich anders aus, als die von
> altehrwürdigen Dienstleistungsbetrieben.
das schon so.
Ja, ich habe auch mit "altehrwürdigen Dienstleistungsbetrieben" zu tun.
Nicht alle sind so drauf, dass dort noch Internet Explorer 8 oder
Uralt-Versionen von Safari das Maß der Dinge ist. HTML5 und Bootstrap
funktioniert da in der Regel problemlos.
Auch in der Welt der "altehrwürdigen Dienstleistungsbetriebe" muss man
spätestens bei Abkündigung von Software (Windows 7, Internet Explorer
etc.) den Schritt gehen, auf eine noch gewartete Version umzustellen,
wenn man keine Sicherheitsprobleme riskieren will.
[...]
>> Nur darüber nachdenken, ob HTML5 nun nach mittlerweile fast 10
>> Jahren nach Veröffentlichung der ersten vollständigen Version
>> irgendwas bringt, wird Dich diesbezüglich nicht weiterbringen.
>
> Natürlich nicht. Seit 2018 sind aber auch schon wieder 4,5 Jahre
> vergangen, und meine Motivation, mir mit relativ viel Mühe das Delta
> seit damals anzueignen, hält sich in sehr überschaubaren Grenzen.
Das Delta ist nicht sonderlich groß. Auch bei HTML5 ist es keineswegs
>> Jahren nach Veröffentlichung der ersten vollständigen Version
>> irgendwas bringt, wird Dich diesbezüglich nicht weiterbringen.
>
> Natürlich nicht. Seit 2018 sind aber auch schon wieder 4,5 Jahre
> vergangen, und meine Motivation, mir mit relativ viel Mühe das Delta
> seit damals anzueignen, hält sich in sehr überschaubaren Grenzen.
so, dass alle paar Monate grundlegende Dinge geändert werden.
Schließlich muss die Browser-Entwicklung auch mithalten.
Siehe die Diskussion um das <button>-Element - alle genannten Attribute
wie "formmethod" oder "formaction" wie wurden bereits von Anfang an
genau so eingeführt und nicht erst in den letzten Jahren hinzugefügt.
Stefan Froehlich
Jul 11, 2022, 7:33:01 AM7/11/22
to
On Mon, 11 Jul 2022 11:03:56 Arno Welzel wrote:
> Stefan Froehlich:
>> On Sun, 10 Jul 2022 21:16:45 Arno Welzel wrote:
>>> Stefan Froehlich:
>>>> Definition nur schwer lösbar. Ich habe daher immer knapp 10
>>>> Jahre Abstand zu aktuellen Entwicklungen gehalten; [...]
> Stefan Froehlich:
>> On Sun, 10 Jul 2022 21:16:45 Arno Welzel wrote:
>>> Stefan Froehlich:
>>>> Definition nur schwer lösbar. Ich habe daher immer knapp 10
>>> Wenn ich so eine Haltung beruflich an den Tag legen würde, wäre
>>> ich arbeitslos.
>> Beim Umstieg auf HTML5 zum Jahreswechsel 2017/18 habe ich mir
>> tatsächlich (und unerwartet) ganz massive Probleme bei einem
>> Kunden eingefangen, [...]
>> tatsächlich (und unerwartet) ganz massive Probleme bei einem
> Lass mich raten: Internet Explorer 10 oder älter?
> Aber zur Einordnung: Internet Explorer 11, mit dem HTML5 schon
> recht problemlos möglich ist, wurde bereits 2013 veröffentlicht
Ich meine, es war die Kombination aus einer Citrix-Umgebung und SAP
R/3, denen man beiden nur unter Verrenkungen und Abhängigkeiten
einen neuen Browser hätte begreiflich machen können - das wollte
sich dort niemand antun, und schon gar nicht *meinetwegen*.
Ein Jahr später ging's dann.
> Ja, wenn man unbedingt solche Kunden bedienen muss, muss man wohl
> Kompromisse eingehen. Dann würde ich die Kosten aber auch
Dieser konkrete Kunde bezahlt, wenn ich es auf's Jahr verteile, grob
2 meiner 12 Monatseinkommen. Angesichts dessen und der
Größenverhältnisse (Einzelunternehmer gegen Großkonzern) frage ich
da nicht lange, sondern passe mich an.
> der Kunde soll schon merken, dass Festhalten an veralteter Technik
> teuer sein kann, sonst tut sich da nichts und man muss auch im
> Jahr 2023 noch Windows 7 und IE 10 berücksichtigen.
einer Abteilung, das Geld von einer ganz anderen, und Konzernlogik
ist nicht formal auflösbar, aber in diesem Fall hat es gepasst.
Nun habe ich aber noch mehr Kandidaten in ähnlicher Größenordnung,
und da sich derartiges vorher nicht so einfach abklären lässt (wer
testet mir das schon durch oder würde auch nur mir eine Testumgebung
der internen Systeme zur Verfügung stellen?), bleibe ich einfach
stockkonservativ. Letztendlich zählt ohnehin, was man mit dem Ding
tun kann, der Wechsel auf HTML5 diente primär *meiner*
Bequemlichkeit.
> Auch in der Welt der "altehrwürdigen Dienstleistungsbetriebe" muss
> man spätestens bei Abkündigung von Software (Windows 7, Internet
> Explorer etc.) den Schritt gehen, auf eine noch gewartete Version
> umzustellen, wenn man keine Sicherheitsprobleme riskieren will.
"echte" Internet haben die Leute andere Browser und andere Netzwerke.
AFAIK lässt sich aber in SAP/Hana der Browser vom Anwender
konfigurieren, so dass sich auch an dieser Front etwas zum positiven
verändern könnte.
> Siehe die Diskussion um das <button>-Element - alle genannten
> Attribute wie "formmethod" oder "formaction" wie wurden bereits
> von Anfang an genau so eingeführt und nicht erst in den letzten
> Jahren hinzugefügt.
nur (mangels Bedarf) längst wieder aus dem Gedächtnis verschwunden.
Auch noch so ein Problem...
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Peter J. Holzer
Jul 11, 2022, 2:26:31 PM7/11/22
to
On 2022-07-10 17:42, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
>> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
>> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
>
> Das ist mein Hauptproblem damit. Im Grund genommen müsste ich mir
> alle paar Jahre den Standard von vorne bis hinten durchlesen, um -
> mit etwas Glück - auf Änderungen zu stoßen.
Das Problem hast Du allerdings bei "numerierten" Standards auch. Da
> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
>> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
>> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
>
> Das ist mein Hauptproblem damit. Im Grund genommen müsste ich mir
> alle paar Jahre den Standard von vorne bis hinten durchlesen, um -
> mit etwas Glück - auf Änderungen zu stoßen.
musst Du im Allgemeinen auch den ganzen Standard lesen, um
herauszufinden, was neu ist. Und dann weißt Du immer noch nicht, was
Deine Ziel-Plattformen auch implementieren. Zumindest bei C hat es nach
C89 und C99[1] doch einige Jahre gedauert, bis der Compiler-Support
einigermaßen brauchbar war, und selbst danach gab es immer wieder
einzelne Features, die gewisse Compiler halt einfach nie implementiert
hatten. War nur insofern einfacher, als ich weniger Plattformen zu
betreuen hatte und die Fehler leichter zu diagnostizieren waren
(Compile-Time-Fehler, die ich sehe statt unerwünschtes
Laufzeit-Verhalten, das ein User sieht).
> Das ist natürlich völlig unpraktikabel, und so ändere ich in letzter
> Zeit eigentlich so gut wie gar nichts mehr, ausser ich stolpere per
> Zufall darüber.
entgegenzuwirken. So viele Probleme, die Kollegen gerne mit dem n+1sten
JavaScript-Framework lösen wollen, lassen sich auch mit ein paar Zeilen
HTML und CSS lösen.
hp
[1] C11 war für mich nicht mehr relevant. Mein letztes größeres
C-Programm habe ich ca. 2012 geschrieben. Seitdem verwende ich das
eigentlich nur mehr für Tests.
Arno Welzel
Jul 11, 2022, 2:45:34 PM7/11/22
to
Peter J. Holzer:
[...]
Framework aus. jQuery wurde primär für Leute gebaut, die wenig tippen
wollen.
Die Anforderung per Framework Unzulänglichkeiten verschiedenster Browser
auszugleichen zu müssen, ist mittlerweile glücklichrweise weitgehend
Geschichte.
[...]
> Ich versuche schon deshalb uptodate zu bleiben, um der Frameworkitis
> entgegenzuwirken. So viele Probleme, die Kollegen gerne mit dem n+1sten
> JavaScript-Framework lösen wollen, lassen sich auch mit ein paar Zeilen
> HTML und CSS lösen.
Und auch bei JavaScript kommt man in sehr vielen Fällen ganz ohne
> entgegenzuwirken. So viele Probleme, die Kollegen gerne mit dem n+1sten
> JavaScript-Framework lösen wollen, lassen sich auch mit ein paar Zeilen
> HTML und CSS lösen.
Framework aus. jQuery wurde primär für Leute gebaut, die wenig tippen
wollen.
Die Anforderung per Framework Unzulänglichkeiten verschiedenster Browser
auszugleichen zu müssen, ist mittlerweile glücklichrweise weitgehend
Geschichte.
Stefan Froehlich
Jul 18, 2022, 8:08:17 AM7/18/22
to
On Mon, 11 Jul 2022 20:26:28 Peter J. Holzer wrote:
> On 2022-07-10 17:42, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>>> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
>>> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
>>> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
>> Das ist mein Hauptproblem damit. Im Grund genommen müsste ich mir
>> alle paar Jahre den Standard von vorne bis hinten durchlesen, um
>> - mit etwas Glück - auf Änderungen zu stoßen.
> Das Problem hast Du allerdings bei "numerierten" Standards auch.
> Da musst Du im Allgemeinen auch den ganzen Standard lesen, um
> herauszufinden, was neu ist. Und dann weißt Du immer noch nicht,
> was Deine Ziel-Plattformen auch implementieren.
Natürlich, das lässt sich nie komplett vermeiden. Aber ich könnte
> On 2022-07-10 17:42, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Sun, 10 Jul 2022 13:27:27 Arno Welzel wrote:
>>> Wünschenswert wäre aber in der Tat, wenn es für Änderungen auch
>>> ein Changelog gäbe, damit man zumindest weiß, ob sich gegenüber
>>> dem Stand, den man kennt, etwas grundlegenderes geändert hat.
>> Das ist mein Hauptproblem damit. Im Grund genommen müsste ich mir
>> alle paar Jahre den Standard von vorne bis hinten durchlesen, um
>> - mit etwas Glück - auf Änderungen zu stoßen.
> Das Problem hast Du allerdings bei "numerierten" Standards auch.
> Da musst Du im Allgemeinen auch den ganzen Standard lesen, um
> herauszufinden, was neu ist. Und dann weißt Du immer noch nicht,
> was Deine Ziel-Plattformen auch implementieren.
mich an einem bestimmten Punkt entscheiden, von HTML5 auf HTML5.1
umzusteigen, mich dann einlesen und - so überhaupt etwas davon
hilfreich ist - die Templates entsprechend anpassen. Das
Release-Datum ist bekannt, meinen Puffer lege ich selber fest, daher
muss ich das je Release *einmal* tun.
Wie mache ich vergleichbares mit einem Living Standard?
Momentan benutze und kenne ich neue Features halt einfach gar nicht,
und erst wenn sie mir zufällig unterkommen, überlege ich, ob sie für
mich nützlich sein könnten.
>> Das ist natürlich völlig unpraktikabel, und so ändere ich in
>> letzter Zeit eigentlich so gut wie gar nichts mehr, ausser ich
>> stolpere per Zufall darüber.
> Ich versuche schon deshalb uptodate zu bleiben, um der
> Frameworkitis entgegenzuwirken. So viele Probleme, die Kollegen
> gerne mit dem n+1sten JavaScript-Framework lösen wollen, lassen
> sich auch mit ein paar Zeilen HTML und CSS lösen.
HTML verantwortlich zu sein. JavaScript-Framework gibt es keines:
wenn ein Feature nicht allgemein einsetzbar ist, wird es gar nicht
verwendet, auch nicht mit Workaround.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jul 18, 2022, 10:15:10 AM7/18/22
to
Stefan Froehlich:
[...]
verinnerlicht und siehst bei HTML 5.1 sofort, was anders ist?
> Release-Datum ist bekannt, meinen Puffer lege ich selber fest, daher
> muss ich das je Release *einmal* tun.
>
> Wie mache ich vergleichbares mit einem Living Standard?
>
> Momentan benutze und kenne ich neue Features halt einfach gar nicht,
> und erst wenn sie mir zufällig unterkommen, überlege ich, ob sie für
> mich nützlich sein könnten.
Vermutlich hast Du HTML 5 noch nie wirklich im Detail angeschaut, wie
viele andere Leute, die HTML nutzen. Solange alles ereicht wird, was
gerade gebraucht wird, ist es ja auch egal. Maximal hat man noch im
Kopf, dass ein anderer doctype verwendet wird, dass es semantische
Elemente wie <header>, <footer>, <aside>, <main> etc. gibt und
Erweiterungen wie <video> und <canvas>. Aber viel mehr wissen viele
Leute oft nicht.
Wie die Lösung zur Frage hier im Thread - ob man <a> mit CSS dazu oder
<button> mit passenden Attributen verwendet, macht im Ergebnis für den
Endbenutzer erstmal keinen großen Unterschied.
Und wenn man sich ein einheitliches CSS überlegt, was sowohl <input
type="button">, <input type="submit"> und <a class="button"> optisch
einheitlich darstellt, kann man auf <button> auch ganz verzichten.
Ist man dagegen interessiert daran, eine Lösung nach Möglichkeit immer
entsprechend dem aktuellen Stand der Dinge umzusetzen, wird man wohl
immer regelmäßig in die Spezifikation schauen und erkennt dann auch ohne
Changelog, was neu ist - eben weil man den Standard gut kennt und
schnell sieht, wenn sich etwas ändert. Ebenso wird man dann regelmäßiger
Angebote wie <https://caniuse.com> nutzen, um zu prüfen, was von welchem
Browser unterstützt wird und hat am Ende einfach Erfahrung. Zur
Sicherheit wird dann noch ein Validator eingesetzt.
[...]
> Natürlich, das lässt sich nie komplett vermeiden. Aber ich könnte
> mich an einem bestimmten Punkt entscheiden, von HTML5 auf HTML5.1
> umzusteigen, mich dann einlesen und - so überhaupt etwas davon
> hilfreich ist - die Templates entsprechend anpassen. Das
Und dann hast Du vorher den Standard zu HTML 5 komplett gelesen und
> mich an einem bestimmten Punkt entscheiden, von HTML5 auf HTML5.1
> umzusteigen, mich dann einlesen und - so überhaupt etwas davon
> hilfreich ist - die Templates entsprechend anpassen. Das
verinnerlicht und siehst bei HTML 5.1 sofort, was anders ist?
> Release-Datum ist bekannt, meinen Puffer lege ich selber fest, daher
> muss ich das je Release *einmal* tun.
>
> Wie mache ich vergleichbares mit einem Living Standard?
>
> Momentan benutze und kenne ich neue Features halt einfach gar nicht,
> und erst wenn sie mir zufällig unterkommen, überlege ich, ob sie für
> mich nützlich sein könnten.
viele andere Leute, die HTML nutzen. Solange alles ereicht wird, was
gerade gebraucht wird, ist es ja auch egal. Maximal hat man noch im
Kopf, dass ein anderer doctype verwendet wird, dass es semantische
Elemente wie <header>, <footer>, <aside>, <main> etc. gibt und
Erweiterungen wie <video> und <canvas>. Aber viel mehr wissen viele
Leute oft nicht.
Wie die Lösung zur Frage hier im Thread - ob man <a> mit CSS dazu oder
<button> mit passenden Attributen verwendet, macht im Ergebnis für den
Endbenutzer erstmal keinen großen Unterschied.
Und wenn man sich ein einheitliches CSS überlegt, was sowohl <input
type="button">, <input type="submit"> und <a class="button"> optisch
einheitlich darstellt, kann man auf <button> auch ganz verzichten.
Ist man dagegen interessiert daran, eine Lösung nach Möglichkeit immer
entsprechend dem aktuellen Stand der Dinge umzusetzen, wird man wohl
immer regelmäßig in die Spezifikation schauen und erkennt dann auch ohne
Changelog, was neu ist - eben weil man den Standard gut kennt und
schnell sieht, wenn sich etwas ändert. Ebenso wird man dann regelmäßiger
Angebote wie <https://caniuse.com> nutzen, um zu prüfen, was von welchem
Browser unterstützt wird und hat am Ende einfach Erfahrung. Zur
Sicherheit wird dann noch ein Validator eingesetzt.
Peter J. Holzer
Jul 19, 2022, 12:26:18 PM7/19/22
to
On 2022-07-18 12:08, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Mon, 11 Jul 2022 20:26:28 Peter J. Holzer wrote:
>> Das Problem hast Du allerdings bei "numerierten" Standards auch.
>> Da musst Du im Allgemeinen auch den ganzen Standard lesen, um
>> herauszufinden, was neu ist. Und dann weißt Du immer noch nicht,
>> was Deine Ziel-Plattformen auch implementieren.
>
> Natürlich, das lässt sich nie komplett vermeiden. Aber ich könnte
> mich an einem bestimmten Punkt entscheiden, von HTML5 auf HTML5.1
> umzusteigen, mich dann einlesen und - so überhaupt etwas davon
> hilfreich ist - die Templates entsprechend anpassen.
Kommt halt darauf an, wie oft es einen neuen Standard gibt - wenn das
> On Mon, 11 Jul 2022 20:26:28 Peter J. Holzer wrote:
>> Das Problem hast Du allerdings bei "numerierten" Standards auch.
>> Da musst Du im Allgemeinen auch den ganzen Standard lesen, um
>> herauszufinden, was neu ist. Und dann weißt Du immer noch nicht,
>> was Deine Ziel-Plattformen auch implementieren.
>
> Natürlich, das lässt sich nie komplett vermeiden. Aber ich könnte
> mich an einem bestimmten Punkt entscheiden, von HTML5 auf HTML5.1
> umzusteigen, mich dann einlesen und - so überhaupt etwas davon
> hilfreich ist - die Templates entsprechend anpassen.
alle 1 bis 2 Jahre der Fall ist, dann ist der Unterschied zu einem
Living Standard schon recht gering. Und in Wirklichkeit ist ja nicht
interessant, was laut Standard funktionieren sollte, sondern was in der
Praxis funktioniert. D.h. Du siehst ein interessantes neues Feature im
Standard, schaust dann auf caniuse nach, wie gut das bereits unterstützt
ist und entscheidest dann, ob du das einsetzen willst oder nicht (und
wenn nicht, kommt es vielleicht auf die "nächstes Jahr wieder
probieren"-Liste). Ob das Feature dann jetzt aus HTML 5.1 oder 5.4
stammt, ist IMHO weitgehend egal.
> Wie mache ich vergleichbares mit einem Living Standard?
richten, sondern kannst Dich jederzeit einlesen, wenn Du gerade Lust
und Zeit hast. Und ich weiß nicht, wie es dir geht, aber ich kenne nicht
alle HTML- und CSS-Features auswendig, ich schaue also ohnehin dauernd
in der Doku nach. Und wenn ich da etwas Brauchbares finde, ist mir
relativ egal, wie alt oder neu das Feature ist - wichtig ist, ob es auf
den Zielsystemen verbreitet genug ist (und wenn nicht, wie das
Fallback-Verhalten ist).
hp
0 new messages