ist Erstellungsdatum einer Website feststellbar?
0 views
Skip to first unread message
Egon Mueller
Feb 28, 2022, 4:32:31 PMFeb 28
to
Hallo
kann man irgendwie herausfinden, wie alt eine Website ist?
Man kann zwar bei der Suche einen Zeitraum angeben, aber wenn man ohne
Zeitlimit-Suche eine Seite geöffnet hat - kann man dann auch noch das
Erstellungs- bzw. Updatedatum herausfinden?
Vielen Dank
mfg
Egon
kann man irgendwie herausfinden, wie alt eine Website ist?
Man kann zwar bei der Suche einen Zeitraum angeben, aber wenn man ohne
Zeitlimit-Suche eine Seite geöffnet hat - kann man dann auch noch das
Erstellungs- bzw. Updatedatum herausfinden?
Vielen Dank
mfg
Egon
Frank
Feb 28, 2022, 4:43:40 PMFeb 28
to
Egon Mueller schrieb:
Hallo Egon,
mit <Strg>+<I> kannst du sowohl bei Firefox als auch bei SeaMonkey die
Seiteninformationen öffnen.
Für statische Webseiten wird hier das Erstellungsdatum angezeigt.
Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
Gruß,
Frank
mit <Strg>+<I> kannst du sowohl bei Firefox als auch bei SeaMonkey die
Seiteninformationen öffnen.
Für statische Webseiten wird hier das Erstellungsdatum angezeigt.
Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
Gruß,
Frank
Egon Mueller
Feb 28, 2022, 5:03:04 PMFeb 28
to
Am 28.02.2022 um 22:43 schrieb Frank:
> Für statische Webseiten wird hier das Erstellungsdatum angezeigt.
> Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
> zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
>
> Gruß,
> Frank
Vielen Dank, es funktioniert!
> Für statische Webseiten wird hier das Erstellungsdatum angezeigt.
> Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
> zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
>
> Gruß,
> Frank
Gruß
Egon
Sebastian Suchanek
Feb 28, 2022, 5:04:56 PMFeb 28
to
Thus spoke Egon Mueller:
Theoretisch ja: Klick auf's Schloss-Symbol in der Adresszeile ->
"Verbindung sicher" -> "Weitere Information" -> "Allgemein" ->
"Modifiziert".
Praktisch eher nicht. Grob geschätzt 99,736% aller Webseiten
werden heutzutage dynamisch erzeugt, da zeigt die o.g.
Information effektiv nur die Zeit des Seitenaufrufes an. Wann
die dahinter stehende(n) Daten(bank) zuletzt aktualisiert wurde,
sieht man so nicht. (Wenn es der Seitenbetreiber nicht
netterweise irgendwo angibt.)
Wenn die fragliche Seite einerseits etwas bekannter ist und
andererseits nicht gerade stündlich aktualisiert wird, bliebe
noch der indirekte Weg über archive.org, die (letzte)
Änderung(en) zeitlich zumindest einzukreisen.
HTH,
Sebastian
PS: <RANT>Welcher UI-Dilettant bei Mozilla ist eigentlich auf
die idiotische Idee gekommen, die Seiteninformationen so gut
zu verstecken!?</RANT>
"Verbindung sicher" -> "Weitere Information" -> "Allgemein" ->
"Modifiziert".
Praktisch eher nicht. Grob geschätzt 99,736% aller Webseiten
werden heutzutage dynamisch erzeugt, da zeigt die o.g.
Information effektiv nur die Zeit des Seitenaufrufes an. Wann
die dahinter stehende(n) Daten(bank) zuletzt aktualisiert wurde,
sieht man so nicht. (Wenn es der Seitenbetreiber nicht
netterweise irgendwo angibt.)
Wenn die fragliche Seite einerseits etwas bekannter ist und
andererseits nicht gerade stündlich aktualisiert wird, bliebe
noch der indirekte Weg über archive.org, die (letzte)
Änderung(en) zeitlich zumindest einzukreisen.
HTH,
Sebastian
PS: <RANT>Welcher UI-Dilettant bei Mozilla ist eigentlich auf
die idiotische Idee gekommen, die Seiteninformationen so gut
zu verstecken!?</RANT>
Axel Berger
Feb 28, 2022, 7:00:22 PMFeb 28
to
Frank wrote:
> Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
> zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
Wenn es so wäre könnte man damit leben, auch wenn z.B. gute Wordpress
> Dynamisch erzeugte Webseiten werden erst zum Zeitpunkt des Abrufs
> zusammengesetzt. Bei diesen steht dort immer das aktuelle Datum.
Themes das Datum des des aus der Datenbank einkopierten Inhalts
anzeigen. Oft ist es aber pure unötige Schlampigkeit, die ein durchaus
vorhandenes und bekannte Datum unterdrückt:
http://axel.berger-odenthal.de/work/Sudel/Filedate.htm
--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --
Frank Miller
Feb 28, 2022, 9:28:15 PMFeb 28
to
Sebastian Suchanek wrote:
> Thus spoke Egon Mueller:
>
>> Hallo
>> kann man irgendwie herausfinden, wie alt eine Website ist?
>>
>> Man kann zwar bei der Suche einen Zeitraum angeben, aber
>> wenn man ohne Zeitlimit-Suche eine Seite geöffnet hat -
>> kann man dann auch noch das Erstellungs- bzw. Updatedatum
>> herausfinden?
>
> Theoretisch ja: Klick auf's Schloss-Symbol in der Adresszeile ->
> "Verbindung sicher" -> "Weitere Information" -> "Allgemein" ->
> "Modifiziert".
[..snip..]
> Thus spoke Egon Mueller:
>
>> Hallo
>> kann man irgendwie herausfinden, wie alt eine Website ist?
>>
>> Man kann zwar bei der Suche einen Zeitraum angeben, aber
>> wenn man ohne Zeitlimit-Suche eine Seite geöffnet hat -
>> kann man dann auch noch das Erstellungs- bzw. Updatedatum
>> herausfinden?
>
> Theoretisch ja: Klick auf's Schloss-Symbol in der Adresszeile ->
> "Verbindung sicher" -> "Weitere Information" -> "Allgemein" ->
> "Modifiziert".
>
> PS: <RANT>Welcher UI-Dilettant bei Mozilla ist eigentlich auf
> die idiotische Idee gekommen, die Seiteninformationen so gut
> zu verstecken!?</RANT>
Naja als Shortcut eben <Strg>+<I>, wie Frank schon schrieb, oder <Alt>
> PS: <RANT>Welcher UI-Dilettant bei Mozilla ist eigentlich auf
> die idiotische Idee gekommen, die Seiteninformationen so gut
> zu verstecken!?</RANT>
(Menüzeile): Extras, Seiteninformationen.
Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
seit geraumer Zeit in Richtung DAU-kompatibel.
Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
Sebastian Suchanek
Mar 1, 2022, 3:13:50 AMMar 1
to
Thus spoke Frank Miller:
> [...]
proof and nature will invent a bigger fool." ;-)
Tschüs,
Sebastian
> [...]
> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei
> Software geht schon seit geraumer Zeit in Richtung
> DAU-kompatibel. Das driftet dann allerdings natürlich zur
> alten Weisheit "Mache eine Sache idiotensicher - und nur
> noch Idioten werden sie benutzen (wollen)".
Ich kenne das ein wenig anders: "Try to make something fool-
> Software geht schon seit geraumer Zeit in Richtung
> DAU-kompatibel. Das driftet dann allerdings natürlich zur
> alten Weisheit "Mache eine Sache idiotensicher - und nur
> noch Idioten werden sie benutzen (wollen)".
proof and nature will invent a bigger fool." ;-)
Tschüs,
Sebastian
Claus Reibenstein
Mar 1, 2022, 10:13:25 AMMar 1
to
Frank Miller schrieb am 01.03.2022 um 03:28:
> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
Man kann eine Sache nicht idiotensicher machen, weil Idioten zu
> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
erfinderisch sind.
Gruß
Claus
Herrand Petrowitsch
Mar 1, 2022, 11:02:13 AMMar 1
to
Claus Reibenstein schrieb:
> Frank Miller schrieb:
>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>
> Man kann eine Sache nicht idiotensicher machen, weil Idioten zu
> erfinderisch sind.
Den Terminus "idiotensicher" sollte man etwas relativieren. :-)
Aus Erfahrung darf ich berichten, dass auch "ganz normale" User ueber
sehr kreative Faehigkeiten verfuegen, um ein - nennen wir es
Informationssystem - auszutricksen. Auch dann, wenn der Hersteller es
als "idiotensicher" bezeichnet. BTDTST.
Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
> Frank Miller schrieb:
>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>
> Man kann eine Sache nicht idiotensicher machen, weil Idioten zu
> erfinderisch sind.
Aus Erfahrung darf ich berichten, dass auch "ganz normale" User ueber
sehr kreative Faehigkeiten verfuegen, um ein - nennen wir es
Informationssystem - auszutricksen. Auch dann, wenn der Hersteller es
als "idiotensicher" bezeichnet. BTDTST.
Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
Eckhard Becker
Mar 1, 2022, 2:16:51 PMMar 1
to
Frank Miller schrieb:
> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
> seit geraumer Zeit in Richtung DAU-kompatibel.
> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
Ich denke schon, dass es sinnvoll ist einen Inhalt möglichst an das
> seit geraumer Zeit in Richtung DAU-kompatibel.
> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
Endgerät angepasst und so weit möglich barrierefrei zu präsentieren und
das auch von Leute, die sich dabei auf den Inhalt und weniger auf die
Gestaltung zu konzentrieren.
Und Spaghetti-Text in 9-Punkt-Schrift ohne Formatierung will und muss
man heute nicht mehr lesen.
Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
Und bei Artikeln, bei denen ein Zeitbezug wichtig ist sollte der im Text
und nicht versteckt in Metadaten stehen.
Wenn ich eine Seite mit "den neuesten Tipps" lese sind die für mich
schon ddeutlich uninteressanter wenn ich erst Aufwand betreiben muss um
festzustellen, dass sie leider schon 2 Jahre alt sind.
E (hat früher auch 100%-HTML ins Netz gestellt und will es heute nicht mehr)
Arno Welzel
Mar 2, 2022, 4:14:33 AMMar 2
to
Sebastian Suchanek:
[...]
Tastenkürzel dafür. Andere Browser haben sowas nicht mal. Vivaldi, Edge
oder Chrome bieten gar eine Möglichkeit an, diese Information einfach
per Menüpunkt anzuzeigen - vermutlich weil die wenigsten Menschen wissen
wollen, wann die angezeigte Seite auf dem Server modifiziert wurde.
Die Ausgabe eines Datums *in* der Seite hat sich dagegen als "best
practice" etabliert und wird von großen Anbietern auch genau so
umgesetzt. Das ist auch deutlich sinnvoller, als eine Funktion des
Browser bemühen zu müssen, um das Änderungsdatum zu erfahren. So sehe
ich als Lese direkt in der Seite, wann sie erstellt oder aktualisiert wurde.
Beispiele:
<https://arnowelzel.de/betterbird>
<https://arnowelzel.de/hdsp-211x-fuer-raspberry-pi>
(Ja, ich gebe bewusst keine Uhrzeit an)
<https://www.golem.de/news/felicity-ace-frachter-mit-4-000-vw-autos-vor-den-azoren-gesunken-2203-163534.html>
<https://www.heise.de/news/Cybergang-Conti-Interne-Daten-geleakt-2-8-Milliarden-US-Dollar-erbeutet-6529035.html>
<https://www.tagesspiegel.de/berlin/eltern-muessen-draussen-bleiben-berliner-kitas-starten-mit-eingeschraenktem-regelbetrieb/28001612.html>
--
Arno Welzel
https://arnowelzel.de
[...]
> PS: <RANT>Welcher UI-Dilettant bei Mozilla ist eigentlich auf
> die idiotische Idee gekommen, die Seiteninformationen so gut
> zu verstecken!?</RANT>
Wieso "verstecken"? Es ist halt ein Menüpunkt und es gibt ein
> die idiotische Idee gekommen, die Seiteninformationen so gut
> zu verstecken!?</RANT>
Tastenkürzel dafür. Andere Browser haben sowas nicht mal. Vivaldi, Edge
oder Chrome bieten gar eine Möglichkeit an, diese Information einfach
per Menüpunkt anzuzeigen - vermutlich weil die wenigsten Menschen wissen
wollen, wann die angezeigte Seite auf dem Server modifiziert wurde.
Die Ausgabe eines Datums *in* der Seite hat sich dagegen als "best
practice" etabliert und wird von großen Anbietern auch genau so
umgesetzt. Das ist auch deutlich sinnvoller, als eine Funktion des
Browser bemühen zu müssen, um das Änderungsdatum zu erfahren. So sehe
ich als Lese direkt in der Seite, wann sie erstellt oder aktualisiert wurde.
Beispiele:
<https://arnowelzel.de/betterbird>
<https://arnowelzel.de/hdsp-211x-fuer-raspberry-pi>
(Ja, ich gebe bewusst keine Uhrzeit an)
<https://www.golem.de/news/felicity-ace-frachter-mit-4-000-vw-autos-vor-den-azoren-gesunken-2203-163534.html>
<https://www.heise.de/news/Cybergang-Conti-Interne-Daten-geleakt-2-8-Milliarden-US-Dollar-erbeutet-6529035.html>
<https://www.tagesspiegel.de/berlin/eltern-muessen-draussen-bleiben-berliner-kitas-starten-mit-eingeschraenktem-regelbetrieb/28001612.html>
--
Arno Welzel
https://arnowelzel.de
Arno Welzel
Mar 2, 2022, 4:18:02 AMMar 2
to
Eckhard Becker:
>
> Frank Miller schrieb:
>> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
>> seit geraumer Zeit in Richtung DAU-kompatibel.
>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>
> Ich denke schon, dass es sinnvoll ist einen Inhalt möglichst an das
> Endgerät angepasst und so weit möglich barrierefrei zu präsentieren und
> das auch von Leute, die sich dabei auf den Inhalt und weniger auf die
> Gestaltung zu konzentrieren.
>
> Und Spaghetti-Text in 9-Punkt-Schrift ohne Formatierung will und muss
> man heute nicht mehr lesen.
>
> Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
Das wird man aber in der Regel mit CSS-Regeln erreichen, die über
media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
> Und bei Artikeln, bei denen ein Zeitbezug wichtig ist sollte der im Text
> und nicht versteckt in Metadaten stehen.
ACK. So machen das Tageszeitungen und Magazine üblicherweise auch. Auch
bei WordPress ist das die Regel.
>
> Frank Miller schrieb:
>> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
>> seit geraumer Zeit in Richtung DAU-kompatibel.
>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>
> Ich denke schon, dass es sinnvoll ist einen Inhalt möglichst an das
> Endgerät angepasst und so weit möglich barrierefrei zu präsentieren und
> das auch von Leute, die sich dabei auf den Inhalt und weniger auf die
> Gestaltung zu konzentrieren.
>
> Und Spaghetti-Text in 9-Punkt-Schrift ohne Formatierung will und muss
> man heute nicht mehr lesen.
>
> Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
> Und bei Artikeln, bei denen ein Zeitbezug wichtig ist sollte der im Text
> und nicht versteckt in Metadaten stehen.
bei WordPress ist das die Regel.
Axel Berger
Mar 2, 2022, 4:55:27 AMMar 2
to
Arno Welzel wrote:
> Wieso "verstecken"?
Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
"select all" und "take screenshot", zwei Dinge die betriebssystemweit in
jedem Fenster und immer gleich gehen und die deshalb niemand in einem
kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
als nur das Erstellungsdatum.
> Es ist halt ein Menüpunkt
Das Erlauben von Seitenfarben -- für die Vollidioten, die relavante
*Inhalte* in CSS *Hintergünden* verstecken -- ist in den aktuellen
Versionen auch tief in Subsubsubmenüs versteckt. Das wäre etwas, wofür
wirklich ein schnelles Kürzel angebracht wäre.
> hat sich dagegen als "best practice" etabliert
Wenn du recht hättest, wäre es nicht so extrem selten und genau da fast
nie zu finden, wo es interessiert.
> Wieso "verstecken"?
Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
"select all" und "take screenshot", zwei Dinge die betriebssystemweit in
jedem Fenster und immer gleich gehen und die deshalb niemand in einem
kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
als nur das Erstellungsdatum.
> Es ist halt ein Menüpunkt
Das Erlauben von Seitenfarben -- für die Vollidioten, die relavante
*Inhalte* in CSS *Hintergünden* verstecken -- ist in den aktuellen
Versionen auch tief in Subsubsubmenüs versteckt. Das wäre etwas, wofür
wirklich ein schnelles Kürzel angebracht wäre.
> hat sich dagegen als "best practice" etabliert
nie zu finden, wo es interessiert.
Arno Welzel
Mar 2, 2022, 6:00:29 AMMar 2
to
Axel Berger:
> Arno Welzel wrote:
>> Wieso "verstecken"?
>
> Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
> "select all" und "take screenshot", zwei Dinge die betriebssystemweit in
> jedem Fenster und immer gleich gehen und die deshalb niemand in einem
"Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
Sowas kann das Betriebsystem nicht machen!
Und "Select all" braucht man im Zweifelsfall auch häufiger als das
Anzeigen irgendwelcher Seiteinformationen.
> kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
> Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
> als nur das Erstellungsdatum.
Und deshalb ist es auch keine "elemtare Grundfunktion", sondern eine
zusätzliche Funktion in einem eigenen Menü. Die Web-Entwickler-Tools
sind noch viel umfangreicher als die Seiteninformationen - und die
erreicht man auch nicht per Kontextmenü, obwohl die für manche Leute
auch als elementare Grundfunktion empfunden werden.
>> Es ist halt ein Menüpunkt
>
> Das Erlauben von Seitenfarben -- für die Vollidioten, die relavante
> *Inhalte* in CSS *Hintergünden* verstecken -- ist in den aktuellen
> Versionen auch tief in Subsubsubmenüs versteckt. Das wäre etwas, wofür
> wirklich ein schnelles Kürzel angebracht wäre.
Sowas habe ich noch NIE(!) gebraucht.
>> hat sich dagegen als "best practice" etabliert
>
> Wenn du recht hättest, wäre es nicht so extrem selten und genau da fast
> nie zu finden, wo es interessiert.
So wie bei Dir?
Beispiele:
<http://berger-odenthal.de>
<http://berger-odenthal.de/Texte/Islam.htm>
<http://berger-odenthal.de/Texte/Moslem-1.htm>
<http://axel.berger-odenthal.de>
<http://axel.berger-odenthal.de/work/Referat/>
<http://axel.berger-odenthal.de/work/Referat/Literatur-Korangenese.htm>
<http://axel.berger-odenthal.de/work/Diplom/>
<http://axel.berger-odenthal.de/work/Diplom/Kap-3.htm#>
Da ist nirgends ein Datum auf der Seite angegeben.
Und Angaben wie "(22-02-26)" sind komplett unsinnig! Wenn das ein an ISO
angelehntes Datum sein soll, sollte das Jahr vierstellig sein, damit man
auch sofort sieht, dass es sich um das Datum handelt und nicht nur
irgendeine Zahlenfolge:
Also nicht (22-02-26) sondern (2022-02-26).
Und auf den einzelnen Seiten ist es mal Deutsch und mal ISO:
<http://berger-odenthal.de/aktuell/a-201227b.htm>
"27. Dezember 2020"
<http://berger-odenthal.de/random/C-210629.htm>
"2021-06-29"
Bevor Du Andere kritisierst, kümmer Dich erstmal um dein eigenes Angebot.
> Arno Welzel wrote:
>> Wieso "verstecken"?
>
> Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
> "select all" und "take screenshot", zwei Dinge die betriebssystemweit in
> jedem Fenster und immer gleich gehen und die deshalb niemand in einem
der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
Sowas kann das Betriebsystem nicht machen!
Und "Select all" braucht man im Zweifelsfall auch häufiger als das
Anzeigen irgendwelcher Seiteinformationen.
> kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
> Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
> als nur das Erstellungsdatum.
zusätzliche Funktion in einem eigenen Menü. Die Web-Entwickler-Tools
sind noch viel umfangreicher als die Seiteninformationen - und die
erreicht man auch nicht per Kontextmenü, obwohl die für manche Leute
auch als elementare Grundfunktion empfunden werden.
>> Es ist halt ein Menüpunkt
>
> Das Erlauben von Seitenfarben -- für die Vollidioten, die relavante
> *Inhalte* in CSS *Hintergünden* verstecken -- ist in den aktuellen
> Versionen auch tief in Subsubsubmenüs versteckt. Das wäre etwas, wofür
> wirklich ein schnelles Kürzel angebracht wäre.
>> hat sich dagegen als "best practice" etabliert
>
> Wenn du recht hättest, wäre es nicht so extrem selten und genau da fast
> nie zu finden, wo es interessiert.
Beispiele:
<http://berger-odenthal.de>
<http://berger-odenthal.de/Texte/Islam.htm>
<http://berger-odenthal.de/Texte/Moslem-1.htm>
<http://axel.berger-odenthal.de>
<http://axel.berger-odenthal.de/work/Referat/>
<http://axel.berger-odenthal.de/work/Referat/Literatur-Korangenese.htm>
<http://axel.berger-odenthal.de/work/Diplom/>
<http://axel.berger-odenthal.de/work/Diplom/Kap-3.htm#>
Da ist nirgends ein Datum auf der Seite angegeben.
Und Angaben wie "(22-02-26)" sind komplett unsinnig! Wenn das ein an ISO
angelehntes Datum sein soll, sollte das Jahr vierstellig sein, damit man
auch sofort sieht, dass es sich um das Datum handelt und nicht nur
irgendeine Zahlenfolge:
Also nicht (22-02-26) sondern (2022-02-26).
Und auf den einzelnen Seiten ist es mal Deutsch und mal ISO:
<http://berger-odenthal.de/aktuell/a-201227b.htm>
"27. Dezember 2020"
<http://berger-odenthal.de/random/C-210629.htm>
"2021-06-29"
Bevor Du Andere kritisierst, kümmer Dich erstmal um dein eigenes Angebot.
Arno Welzel
Mar 2, 2022, 6:02:43 AMMar 2
to
Arno Welzel:
> Axel Berger:
>
>> Arno Welzel wrote:
>>> Wieso "verstecken"?
>>
>> Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
>> "select all" und "take screenshot", zwei Dinge die betriebssystemweit in
>> jedem Fenster und immer gleich gehen und die deshalb niemand in einem
>
> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
>
> Sowas kann das Betriebsystem nicht machen!
>
> Und "Select all" braucht man im Zweifelsfall auch häufiger als das
> Anzeigen irgendwelcher Seiteinformationen.
>
>> kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
>> Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
>> als nur das Erstellungsdatum.
>
> Und deshalb ist es auch keine "elemtare Grundfunktion", sondern eine
> zusätzliche Funktion in einem eigenen Menü. Die Web-Entwickler-Tools
> sind noch viel umfangreicher als die Seiteninformationen - und die
> erreicht man auch nicht per Kontextmenü, obwohl die für manche Leute
> auch als elementare Grundfunktion empfunden werden.
Korrektur:
Doch, über "Untersuchen" im Kontextmenü gehen natürlich auch die
Web-Entwicklertools auf. Ich hatte allerdings den Menüpunkt im
Extras-Menü dabei im Kopf.
> Axel Berger:
>
>> Arno Welzel wrote:
>>> Wieso "verstecken"?
>>
>> Es war vorher im Rechtsklick, wo so etwas hingehört. Jetzt ist da
>> "select all" und "take screenshot", zwei Dinge die betriebssystemweit in
>> jedem Fenster und immer gleich gehen und die deshalb niemand in einem
>
> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
>
> Sowas kann das Betriebsystem nicht machen!
>
> Und "Select all" braucht man im Zweifelsfall auch häufiger als das
> Anzeigen irgendwelcher Seiteinformationen.
>
>> kontextabhängigen Menü braucht, aber nicht mehr eine elemetare
>> Grundfunktion für Seiten im Web. In "Info" steckt ja noch erheblich mehr
>> als nur das Erstellungsdatum.
>
> Und deshalb ist es auch keine "elemtare Grundfunktion", sondern eine
> zusätzliche Funktion in einem eigenen Menü. Die Web-Entwickler-Tools
> sind noch viel umfangreicher als die Seiteninformationen - und die
> erreicht man auch nicht per Kontextmenü, obwohl die für manche Leute
> auch als elementare Grundfunktion empfunden werden.
Doch, über "Untersuchen" im Kontextmenü gehen natürlich auch die
Web-Entwicklertools auf. Ich hatte allerdings den Menüpunkt im
Extras-Menü dabei im Kopf.
Axel Berger
Mar 2, 2022, 10:55:09 AMMar 2
to
Arno Welzel wrote:
> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
Danke. Gut zu wissen. Und da hätte ich bei dem wohldefinierten Begriff
> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
genau wie drauf kommen können? Für "copy page as image" oder "as
graphic" hat deren Englisch nicht gereicht? Da können sie in den
Menüpunkt auch gleich "shoot mother in-law" reinschreiben, ist gleich
hilfreich.
> Und "Select all" braucht man im Zweifelsfall auch häufiger als das
> Anzeigen irgendwelcher Seiteinformationen.
Nö. Nach dem Selektieren wird man mit der Selektion irgendwas machen
wollen. Wie? Vor <Ctrl><C> kann ich mühelos auch gleich <Ctrl><A>
machen.
> Die Web-Entwickler-Tools
> erreicht man auch nicht per Kontextmenü, obwohl die für manche Leute
> auch als elementare Grundfunktion empfunden werden.
Richtig. Wären die dort, fiele es mir nicht im Traum ein, sie wie die
beiden o.g. überflüssig zu nennen.
> So wie bei Dir?
> Da ist nirgends ein Datum auf der Seite angegeben.
Du hast teilweise recht. Da stecken etliche Altlasten mit Mängeln drin.
Aber das gilt nicht für alles. Allgemeine Übersichtsseiten brauche kein
Datum und die Links darin sind wo überhaupt sinnvoll fast immer datiert.
Was mich ärgert sind Seiten wie
http://berger-odenthal.de/random/C-001840.htm
Da gehört das Datum unter die Überschrift, fehlt aber. Der Blog war mal
unter Wordpress und wurde per Skript aus dem Export gewandelt. Wordpress
hatte das Datum automatisch eingestzt. Entweder es stand im Export nicht
drin oder ich habe bei der Wandlung einen groben Fehler gemacht. Ist
jetzt auch schon wieder länger her.
Eckhard Becker
Mar 2, 2022, 1:37:53 PMMar 2
to
Arno Welzel schrieb:
> Eckhard Becker:
>
>>
>> Frank Miller schrieb:
>>> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
>>> seit geraumer Zeit in Richtung DAU-kompatibel.
>>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>>
>> Ich denke schon, dass es sinnvoll ist einen Inhalt möglichst an das
>> Endgerät angepasst und so weit möglich barrierefrei zu präsentieren und
>> das auch von Leute, die sich dabei auf den Inhalt und weniger auf die
>> Gestaltung zu konzentrieren.
>>
>> Und Spaghetti-Text in 9-Punkt-Schrift ohne Formatierung will und muss
>> man heute nicht mehr lesen.
>>
>> Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
>
> Das wird man aber in der Regel mit CSS-Regeln erreichen, die über
> media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
> Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
> User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
Wer definiert was üblich ist und was fehlerträchtig?
>
>>
>> Frank Miller schrieb:
>>> Aber dennoch gebe ich dir Recht. Die UI-Tendenz bei Software geht schon
>>> seit geraumer Zeit in Richtung DAU-kompatibel.
>>> Das driftet dann allerdings natürlich zur alten Weisheit "Mache eine Sache
>>> idiotensicher - und nur noch Idioten werden sie benutzen (wollen)".
>>
>> Ich denke schon, dass es sinnvoll ist einen Inhalt möglichst an das
>> Endgerät angepasst und so weit möglich barrierefrei zu präsentieren und
>> das auch von Leute, die sich dabei auf den Inhalt und weniger auf die
>> Gestaltung zu konzentrieren.
>>
>> Und Spaghetti-Text in 9-Punkt-Schrift ohne Formatierung will und muss
>> man heute nicht mehr lesen.
>>
>> Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
>
> Das wird man aber in der Regel mit CSS-Regeln erreichen, die über
> media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
> Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
> User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
Einmal muss es der Entwickler der Serversoftware machen und einmal
jemand, der evtl. lieber Text als Code schreibt individuell. Was da
fehlerärmer oder für den Leser besser ist?
Wenn das alles per CSS gemacht wird muss sich das i.a. schwächere
Endgerät drum kümmern.
Ich bin nicht traurig, wenn Bilder auf dem Server auf die passende Größe
skaliert wird und nicht erst komplett z.B. auf das Smartphone geladen
werden muss und dann runterskaliert wird. Das Ergebnis ist sonst u.U.
schlechter, sicher aber verbraucht es mehr Datenvolumen,
Berechnungsszeit und Akkukapazität.
>> Und bei Artikeln, bei denen ein Zeitbezug wichtig ist sollte der im Text
>> und nicht versteckt in Metadaten stehen.
>
> ACK. So machen das Tageszeitungen und Magazine üblicherweise auch. Auch
> bei WordPress ist das die Regel.
E.
Arno Welzel
Mar 3, 2022, 8:41:56 AMMar 3
to
Eckhard Becker:
> Arno Welzel schrieb:
>> Eckhard Becker:
[...]
automatisch so. User-Agents zu erkennen *IST* fehleranfällig, weil sich
die ständig ändern. Dauernd kommen neue Browserkennungen dazu und
dauernd muss man endlose Listen aktuell halten, damit die Aussage "ist
ein Smartphone" zuverlässig treffen kann.
Dagegen ist eine CSS-Media-Query, die festlegt, wie Elemente auf einem
schmalen Smartphone-Display aussehen sollen, *immer* nutzbar, ganz egal
welcher Browser verwendet wird.
> Einmal muss es der Entwickler der Serversoftware machen und einmal
> jemand, der evtl. lieber Text als Code schreibt individuell. Was da
> fehlerärmer oder für den Leser besser ist?
Die Lösung per CSS ist immer die bessere.
> Wenn das alles per CSS gemacht wird muss sich das i.a. schwächere
> Endgerät drum kümmern.
Das Endgerät ist nicht schwächer. Selbst Smartphones haben heutzutage
schon Mehrkern-CPUs und mehrere GB Speicher - ganz exklusiv nur für den
Endbenutzer. Der Server dagegen muss hunderte oder tausende Clients
versorgen und hat oft auch kaum mehr Leistung, gerade wenn es um Shared
Hosting geht.
> Ich bin nicht traurig, wenn Bilder auf dem Server auf die passende Größe
> skaliert wird und nicht erst komplett z.B. auf das Smartphone geladen
> werden muss und dann runterskaliert wird. Das Ergebnis ist sonst u.U.
> schlechter, sicher aber verbraucht es mehr Datenvolumen,
> Berechnungsszeit und Akkukapazität.
Ähm - nein. Siehe auch hier:
<https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images>
[...]
> Arno Welzel schrieb:
>> Eckhard Becker:
>>> Die dynamische Aufbereitung finde ich da einen Vorteil nicht nur für DAUs.
>>
>> Das wird man aber in der Regel mit CSS-Regeln erreichen, die über
>> media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
>> Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
>> User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
> Wer definiert was üblich ist und was fehlerträchtig?
Das muss man nicht definieren - das ergibt sich in der Praxis
>>
>> Das wird man aber in der Regel mit CSS-Regeln erreichen, die über
>> media-query-Regeln eine an das Endgerät angepasste Darstellung liefern.
>> Die Ausgabe statt dessen severseitig über den vom Browser gemeldeten
>> User-Agent anzupassen, ist fehlerträchtig und deshalb auch nicht üblich.
> Wer definiert was üblich ist und was fehlerträchtig?
automatisch so. User-Agents zu erkennen *IST* fehleranfällig, weil sich
die ständig ändern. Dauernd kommen neue Browserkennungen dazu und
dauernd muss man endlose Listen aktuell halten, damit die Aussage "ist
ein Smartphone" zuverlässig treffen kann.
Dagegen ist eine CSS-Media-Query, die festlegt, wie Elemente auf einem
schmalen Smartphone-Display aussehen sollen, *immer* nutzbar, ganz egal
welcher Browser verwendet wird.
> Einmal muss es der Entwickler der Serversoftware machen und einmal
> jemand, der evtl. lieber Text als Code schreibt individuell. Was da
> fehlerärmer oder für den Leser besser ist?
> Wenn das alles per CSS gemacht wird muss sich das i.a. schwächere
> Endgerät drum kümmern.
schon Mehrkern-CPUs und mehrere GB Speicher - ganz exklusiv nur für den
Endbenutzer. Der Server dagegen muss hunderte oder tausende Clients
versorgen und hat oft auch kaum mehr Leistung, gerade wenn es um Shared
Hosting geht.
> Ich bin nicht traurig, wenn Bilder auf dem Server auf die passende Größe
> skaliert wird und nicht erst komplett z.B. auf das Smartphone geladen
> werden muss und dann runterskaliert wird. Das Ergebnis ist sonst u.U.
> schlechter, sicher aber verbraucht es mehr Datenvolumen,
> Berechnungsszeit und Akkukapazität.
<https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images>
[...]
>>> Und bei Artikeln, bei denen ein Zeitbezug wichtig ist sollte der im Text
>>> und nicht versteckt in Metadaten stehen.
>>
>> ACK. So machen das Tageszeitungen und Magazine üblicherweise auch. Auch
>> bei WordPress ist das die Regel.
> Bei erschreckend vielen Artikeln von Privatleuten leider nicht.
Dann muss man es ihnen sagen. Von alleine ändert sich daran nichts.
>>> und nicht versteckt in Metadaten stehen.
>>
>> ACK. So machen das Tageszeitungen und Magazine üblicherweise auch. Auch
>> bei WordPress ist das die Regel.
> Bei erschreckend vielen Artikeln von Privatleuten leider nicht.
Arno Welzel
Mar 3, 2022, 8:47:04 AMMar 3
to
Axel Berger:
> Arno Welzel wrote:
>> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
>> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
>> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
>
> Danke. Gut zu wissen. Und da hätte ich bei dem wohldefinierten Begriff
> genau wie drauf kommen können? Für "copy page as image" oder "as
> graphic" hat deren Englisch nicht gereicht? Da können sie in den
> Menüpunkt auch gleich "shoot mother in-law" reinschreiben, ist gleich
> hilfreich.
Schreibe einen Bugreport bei <https://bugzilla.mozilla.org> oder
akzeptiere es.
>> Und "Select all" braucht man im Zweifelsfall auch häufiger als das
>> Anzeigen irgendwelcher Seiteinformationen.
>
> Nö. Nach dem Selektieren wird man mit der Selektion irgendwas machen
> wollen. Wie? Vor <Ctrl><C> kann ich mühelos auch gleich <Ctrl><A>
> machen.
Es gibt Menschen, die können eine Maus oder Maus-ähnliche Hilfsmittel
benutzen, aber nicht unbedingt eine Tastatur.
[...]
nutze WordPress ;-).
Warum Du davon wieder zurück auf statisches HTML gewechselt hast, ist
für mich nur schwer nachvollziehbar.
> Arno Welzel wrote:
>> "Take screenshot" erstellt einen auf Wunsch auch einen Screenshot von
>> der *Website* und nicht vom Bildschirm! D.h. da wird die *komplette*
>> Website abgespeichert und nicht nur der gerade sichtbare Teil im Fenster.
>
> Danke. Gut zu wissen. Und da hätte ich bei dem wohldefinierten Begriff
> genau wie drauf kommen können? Für "copy page as image" oder "as
> graphic" hat deren Englisch nicht gereicht? Da können sie in den
> Menüpunkt auch gleich "shoot mother in-law" reinschreiben, ist gleich
> hilfreich.
akzeptiere es.
>> Und "Select all" braucht man im Zweifelsfall auch häufiger als das
>> Anzeigen irgendwelcher Seiteinformationen.
>
> Nö. Nach dem Selektieren wird man mit der Selektion irgendwas machen
> wollen. Wie? Vor <Ctrl><C> kann ich mühelos auch gleich <Ctrl><A>
> machen.
benutzen, aber nicht unbedingt eine Tastatur.
[...]
>> So wie bei Dir?
>> Da ist nirgends ein Datum auf der Seite angegeben.
>
> Du hast teilweise recht. Da stecken etliche Altlasten mit Mängeln drin.
> Aber das gilt nicht für alles. Allgemeine Übersichtsseiten brauche kein
> Datum und die Links darin sind wo überhaupt sinnvoll fast immer datiert.
>
> Was mich ärgert sind Seiten wie
> http://berger-odenthal.de/random/C-001840.htm
>
> Da gehört das Datum unter die Überschrift, fehlt aber. Der Blog war mal
> unter Wordpress und wurde per Skript aus dem Export gewandelt. Wordpress
> hatte das Datum automatisch eingestzt. Entweder es stand im Export nicht
> drin oder ich habe bei der Wandlung einen groben Fehler gemacht. Ist
> jetzt auch schon wieder länger her.
"Wordpress hatte das Datum automatisch eingestzt."
Ja - genau deswegen (und wegen vieler anderer nützliche Funktionen)
>> Da ist nirgends ein Datum auf der Seite angegeben.
>
> Du hast teilweise recht. Da stecken etliche Altlasten mit Mängeln drin.
> Aber das gilt nicht für alles. Allgemeine Übersichtsseiten brauche kein
> Datum und die Links darin sind wo überhaupt sinnvoll fast immer datiert.
>
> Was mich ärgert sind Seiten wie
> http://berger-odenthal.de/random/C-001840.htm
>
> Da gehört das Datum unter die Überschrift, fehlt aber. Der Blog war mal
> unter Wordpress und wurde per Skript aus dem Export gewandelt. Wordpress
> hatte das Datum automatisch eingestzt. Entweder es stand im Export nicht
> drin oder ich habe bei der Wandlung einen groben Fehler gemacht. Ist
> jetzt auch schon wieder länger her.
"Wordpress hatte das Datum automatisch eingestzt."
nutze WordPress ;-).
Warum Du davon wieder zurück auf statisches HTML gewechselt hast, ist
für mich nur schwer nachvollziehbar.
Reply all
Reply to author
Forward
0 new messages