nicht angemeldet
Gunnar Bittersmann
Tabellenkalk
TS
Matthias Apsel
TS
Matthias Apsel
Gunnar Bittersmann
Tabellenkalk
Tabellenkalk
Gunnar Bittersmann
Hallo zusammen,
erst mal ein großes Lob an die Seite - hat mir schon über einiges Info's und Anregungen gegeben!!
Zu meiner Frage. Ich möchte mir eine Homepage schreiben, finde auch an ganz vielen Stellen in Foren und über Google wie ich eine Navigation aufbaue, jedoch leider hören alle Artikel / Videos auf nach dem die Navigationsleiste steht.
Bisher klar ist folgender Aufbau mit Hilfe der Dateien "index.html/php" und "style.css":
Auge<nav class="nav">
<ul>
<li><a href="#home">Home</a></li>
<li><a href="#seite1">Seite 1</a></li>
<li><a href="#seite2">Seite 2</a></li>
<li><a href="#seite3">Seite 3</a></li>
...
damit schaffe ich es auch dass die URL "meineseite.de/index.html#seite2" aufgerufen werden soll, jedoch bleibe ich immer auf meiner index Seite hängen, da ich nicht weiß wie ich jetzt #seite2 anlegen soll...
Alternativ gibt es ja die Möglichkeit die Navigation mit "<li><a href="seite2.html">Seite 2</a></li> aufzubauen, dann schickt es mich auch direkt auf Seite 2 wenn ich dem Link folge, so weite so gut. Leider gibt es jetzt das Problem dass ich nicht auf jeder meiner Seiten die Navigation aktuell halten möchte. Sollte es mal 30 Seiten geben und es kommt eine 31. dazu muss ich diese in 30 Seiten hinzufügen - das sollte doch nicht Stand der Technik sein :D
Wäre schön jemand könnte mich im Thema #seite und "nav" ein wenig aufklären, entweder ich suche bisher falsch oder es wird zu selten der Zusammenhang zwischen Navigation und weiteren Seiten erklärt.
Vielen Dank fürs lesen - bin natürlich auch offen für weitere Vorschläge eine Navigation aufzubauen :)
Grüße
Chris
@@chrisproud
Info's
Der Apostroph macht keinen Sinn.
<nav class="nav">
Die Klasse macht keinen Sinn.
Leider gibt es jetzt das Problem dass ich nicht auf jeder meiner Seiten die Navigation aktuell halten möchte.
https://wiki.selfhtml.org/wiki/PHP/Tutorials/Dateien_mittels_include_einbinden macht Sinn.
LLAP 🖖
@@Gunnar Bittersmann
https://wiki.selfhtml.org/wiki/PHP/Tutorials/Dateien_mittels_include_einbinden macht Sinn.
… wenn das Include denn auch PHP-Code enthält, der geparst werden muss. Ansonsten was Ashura sagte.
LLAP 🖖
@@Gunnar Bittersmann
https://wiki.selfhtml.org/wiki/PHP/Tutorials/Dateien_mittels_include_einbinden macht Sinn.
… wenn das Include denn auch PHP-Code enthält, der geparst werden muss. Ansonsten was Ashura sagte.
Obwohl ich mir mir nicht so sicher bin, ob das wirklich ein so guter Ratschlag ist. Wieviele Mikrosekunden spart der Server dadurch?
Auf der Kehrseite hat man mit readfile keinen single point of change mehr. Wenn man das Include ändert und es dann doch PHP-Code enthält, müsste man zusätzlich die Einbindung von readfile auf include (o.ä.) ändern – und das auf allen Seiten.
Das sollte dafür sprechen, gleich include (o.ä.) zu verwenden, oder?
LLAP 🖖
Hallo
Auf der Kehrseite hat man mit
readfilekeinen single point of change mehr. Wenn man das Include ändert und es dann doch PHP-Code enthält, müsste man zusätzlich die Einbindung vonreadfileaufinclude(o.ä.) ändern – und das auf allen Seiten.Das sollte dafür sprechen, gleich
include(o.ä.) zu verwenden, oder?
Wenn man sicher ist, dass in der einzubindenden Datei kein ausführbarer Code enthalten ist, der Inhalt also einfach nur durchgereicht wird, ist readfile zu bevorzugen. Abseits von etwaig eingesparten Mikrosekunden kann einem auch nichts untergeschoben werden. Da es hier aber um die Einbindung einer Navigation geht, bei der man, wenn man sie schon mit PHP einbindet, mit großer Wahrscheinlichkeit auch seitenspezifische Anpassungen vornehmen will, ist include (mit einiger Wahrscheinlichkeit mit _once) die sinnvollere Wahl.
Tschö, Auge
@@Auge
Da es hier aber um die Einbindung einer Navigation geht, bei der man, wenn man sie schon mit PHP einbindet, mit großer Wahrscheinlichkeit auch seitenspezifische Anpassungen vornehmen will
Die Abfrage der aktuellen Seite und Nichtverlinkung dieser im Menü fällt mir dazu ein.
LLAP 🖖
Tach!
Die Abfrage der aktuellen Seite und Nichtverlinkung dieser im Menü fällt mir dazu ein.
Manchmal klicke ich im Wiki auf den Link zur aktuellen Seite. Absichtlich. Und ich kann auch erkennen, dass es der Link zur aktuellen Seite ist.
Ein Link zu aktuellen Seite ist insbesondere dann nicht unsinnig, wenn dadurch Aktionen ausgelöst oder Zustände herbeigeführt werden, die man beim Neuladen der Seite ausgelöst oder herbeigeführt haben möchte. Ich finde wichtiger als die Vermeidung der Verlinkung ist eine Kennzeichnung, welcher Menüpunkt aktiv ist. Eine gekennzeichnete Selbstverlinkung schadet meiner Meinung nach weniger als die Unannehmlichkeit, keinen Link zu haben, wenn man ihn gern hätte.
dedlfix.
Hallo und guten Morgen Dedlfix,
Ein Link zu aktuellen Seite ist insbesondere dann nicht unsinnig, wenn dadurch Aktionen ausgelöst oder Zustände herbeigeführt werden, die man beim Neuladen der Seite ausgelöst oder herbeigeführt haben möchte. Ich finde wichtiger als die Vermeidung der Verlinkung ist eine Kennzeichnung, welcher Menüpunkt aktiv ist. Eine gekennzeichnete Selbstverlinkung schadet meiner Meinung nach weniger als die Unannehmlichkeit, keinen Link zu haben, wenn man ihn gern hätte.
Dieses angebliche "Nogo" stammt mMn noch aus der Zeit, in der die Bot-Programme noch zu doof waren zu erkennen, dass sie sich aufhängen, also in eine Schleife liefen.
Grüße
TS
@@TS
Dieses angebliche "Nogo" stammt mMn noch aus der Zeit, in der die Bot-Programme noch zu doof waren zu erkennen, dass sie sich aufhängen, also in eine Schleife liefen.
Selbst wenn da ein temporärer Zusammenhang besteht, gewiss kein kausaler. Nielsen spricht von (menschlichen!) Nutzern.
LLAP 🖖
@@dedlfix
Ein Link zu aktuellen Seite ist insbesondere dann nicht unsinnig, wenn dadurch Aktionen ausgelöst oder Zustände herbeigeführt werden, die man beim Neuladen der Seite ausgelöst oder herbeigeführt haben möchte.
Ich sage es gern immer wieder: Navigation und Aktualisierung von Daten sind zwei völlig verschiedene Nutzeraktionen. Auch wenn technisch dasselbe dahintersteckt.
Verschiedene Nutzeraktionen heißt verschiedene UI-Elemente dafür. Wenn man Daten akualisieren möchte, warum sollte man das im Navigationsmenü tun? Weil es einmal da ist? Schlechter Grund. Entwicklersicht, nicht nutzerzentriert.
LLAP 🖖
Tach!
Verschiedene Nutzeraktionen heißt verschiedene UI-Elemente dafür. Wenn man Daten akualisieren möchte, warum sollte man das im Navigationsmenü tun? Weil es einmal da ist? Schlechter Grund. Entwicklersicht, nicht nutzerzentriert.
Weil das der Punkt war, über den ich zu diesen Daten gelangt bin. Warum soll ich mir nun einen weiteren Punkt suchen müssen, an dem ich dasselbe erreiche? Nur weil der Entwickler meint, da dürfe kein Link sein? Du kannst ja gern noch eine weitere Schaltfläche für das Aktualisieren anbieten, aber ich sehe da noch keinen Grund, warum der Menüpunkt unbedingt deaktiviert werden müsse.
dedlfix.
@@dedlfix
Weil das der Punkt war, über den ich zu diesen Daten gelangt bin.
Wenn man schon dort ist, sucht man nach dem Wegweiser, wie man dorthin gekommen ist?
Vielleicht. Vielleicht nicht. Mit einem Nutzertest könnte man es herausfinden.
Du kannst ja gern noch eine weitere Schaltfläche für das Aktualisieren anbieten
Sollte? Es gibt bereits eine solche: den Refresh-Button des Browsers.
Der sollte genügen – auch das wäre mit einem Nutzertest herauszufinden.
LLAP 🖖
Hallo
Weil das der Punkt war, über den ich zu diesen Daten gelangt bin.
Wenn man schon dort ist, sucht man nach dem Wegweiser, wie man dorthin gekommen ist?
Ich weiß ja nicht, wie es mit deinem Gedächtnis bestellt ist, aber ich müsste nicht nach dem Weg suchen, auf dem ich irgendwo hingekommen bin, da ich ihn soeben beschritten habe. Was soll man (also alle außer dir) da suchen müssen?
Natürlich kann man die Reload-Schaltflächen und Tastenkombis des Browsers oder eine explizit dafür vorgesehene Schaltfläche auf der Webseite benutzen. Man kann aber auch den Menüpunkt mit dem Link zur aktuellen Seite benutzen wollen, weil man (also alle außer dir) schon weiß, wo der ist. In manchen Fällen ist das Angebot, die Seite mit diesem Link zu aktualisieren, ein gutes, hilfreiches Angebot, das viele menschliche(!) Benutzer gerne annehmen. Und auch das wäre mit einem Nutzertest herauszufinden.
Tschö, Auge
Hallo und guten Morgen,
Natürlich kann man die Reload-Schaltflächen und Tastenkombis des Browsers oder eine explizit dafür vorgesehene Schaltfläche auf der Webseite benutzen. Man kann aber auch den Menüpunkt mit dem Link zur aktuellen Seite benutzen wollen, weil man (also alle außer dir) schon weiß, wo der ist. In manchen Fällen ist das Angebot, die Seite mit diesem Link zu aktualisieren, ein gutes, hilfreiches Angebot, das viele menschliche(!) Benutzer gerne annehmen. Und auch das wäre mit einem Nutzertest herauszufinden.
Die beiden haben doch vollkommen unterschiedliche Auswirkungen. Der Link führt immer (außer bei JS-Vermatschungen) zu einem erneuten GET der Ressource, die sich hinter dem Link versteckt. Der Button führt zu einem RELOAD, was auch ein POST-Request sein kann.
Wenn man also z. B. über ein Formular wieder in das Gleiche (also eine neue Instanz des Formulars) zurückgeführt wird, würde der Klick auf den Link das Formular generisch neu aufrufen, der Button aber den POST zu wiederholen versuchen.
Es kann also durchaus sinnvoll sein, dem Clientuser den Hinweis zu geben, bitte eben NICHT die browsereigenen Funktionselemente Reload, History-Back oder History-Forward zu benutzen.
Man kann (und darf mMn) hier also gar keinen allgemeinen Rat geben. Nur weil Pippi Langstrumpf oder der Affe Nielson das in irgendeinem Dossier niedergeschrieben haben, wird es nicht allgemeingültig. :-P
Grüße
TS
Hallo
[Man] kann … die Reload-Schaltflächen und Tastenkombis des Browsers oder eine … Schaltfläche auf der Webseite … aber auch den Menüpunkt mit dem Link zur aktuellen Seite benutzen …
Die beiden haben doch vollkommen unterschiedliche Auswirkungen. Der Link führt immer (außer bei JS-Vermatschungen) zu einem erneuten GET der Ressource, die sich hinter dem Link versteckt. Der Button führt zu einem RELOAD, was auch ein POST-Request sein kann.
Wenn man also z. B. über ein Formular wieder in das Gleiche (also eine neue Instanz des Formulars) zurückgeführt wird, würde der Klick auf den Link das Formular generisch neu aufrufen, der Button aber den POST zu wiederholen versuchen.
Hier war nicht explizit von Formularen die Rede. Es ging allgemeiner um einen Reload der Seite, um aktuelle Änderungen darzustellen. Der Umgang mit Formularen ist da ein (natürlich nicht zu vernachlässigender) Spezialfall.
Es kann also durchaus sinnvoll sein, dem Clientuser den Hinweis zu geben, bitte eben NICHT die browsereigenen Funktionselemente Reload, History-Back oder History-Forward zu benutzen.
Wäre es nicht sinnvoller, gerade bezüglich potentieller Probleme mit Formularen, dafür zu sorgen, dass es nicht zu doppelten Einträgen/Änderungen etc. kommen kann, als dem Benutzer mit „Tue dies nicht, lasse das sein!“ zu kommen?
Tschö, Auge
Hallo und guten Tag,
Wäre es nicht sinnvoller, gerade bezüglich potentieller Probleme mit Formularen, dafür zu sorgen, dass es nicht zu doppelten Einträgen/Änderungen etc. kommen kann, als dem Benutzer mit „Tue dies nicht, lasse das sein!“ zu kommen?
Treib's nicht zu weit ;-)
Es ging hier nur darum klarzumachen, dass ein Link und ein Reload-Button vollkommen unterschiedliche Funktionen ausführen. Und damit man das auch verstehen kann, habe ich ein Beispiel genannt. Beispiele haben meistens die Eigenschaft, irgendwie spezieller zu sein, als einfache oberflächliche Beschreibungen.
Grüße
TS
@@Auge
Hier war nicht explizit von Formularen die Rede. Es ging allgemeiner um einen Reload der Seite, um aktuelle Änderungen darzustellen.
Ursprünglich ging es auch gar nicht um Webseiten, auf denen sich Daten häufig ändern. Den Aspekt hatte dedlfix erst in die Runde geworfen.
LLAP 🖖
Hallo
Hier war nicht explizit von Formularen die Rede. Es ging allgemeiner um einen Reload der Seite, um aktuelle Änderungen darzustellen.
Ursprünglich ging es auch gar nicht um Webseiten, auf denen sich Daten häufig ändern. Den Aspekt hatte dedlfix erst in die Runde geworfen.
Da hast du recht. Also konkretisiere ich:
Hier*, im hiesigen Ast der Diskussion,* war nicht explizit von Formularen die Rede. Es ging allgemeiner um einen Reload der Seite, um aktuelle Änderungen darzustellen.
Tschö, Auge
Tach!
Ursprünglich ging es auch gar nicht um Webseiten, auf denen sich Daten häufig ändern. Den Aspekt hatte dedlfix erst in die Runde geworfen.
Hab ich häufig gesagt? Selbst wenn sie sich nicht häufig ändern, möchte man sie mitunter gern mal neu laden. Als der Herr Nielsen seine Top-10-Mistakes veröffentlichte, war die Welt noch eine ganz andere. Da hat er auch eine Regel formuliert, dass man die Linkfarbe nicht anfassen soll. Links sollen blau sein, das ist das was der Anwender kennt. Das war vor 20 Jahren. Vor 12 Jahren hatte er dazu schon eine anderen Meinung. Die Zeiten und die Notwendigkeiten ändern sich. Es ist immer noch wichtig, den Anwender nicht zu verwirren. Man muss diese Hinweise an die Autoren aber auch nicht als uraltes Dogma rüberbringen. Das verstellt nur unnötig den Blick auf Alternativen, die ebensogut sind.
dedlfix.
Hallo TS,
Es kann also durchaus sinnvoll sein, dem Clientuser den Hinweis zu geben, bitte eben NICHT die browsereigenen Funktionselemente Reload, History-Back oder History-Forward zu benutzen.
Nein, das kann nie sinnvoll sein (und das wird erfahrungsgemäss auch nicht funktionieren).
LG,
CK
Tach!
Weil das der Punkt war, über den ich zu diesen Daten gelangt bin.
Wenn man schon dort ist, sucht man nach dem Wegweiser, wie man dorthin gekommen ist?
Ja, den suche ich, und zwar auf, weil ich den Weg schon kenne.
Du kannst ja gern noch eine weitere Schaltfläche für das Aktualisieren anbieten
Sollte? Es gibt bereits eine solche: den Refresh-Button des Browsers.
Der sollte genügen – auch das wäre mit einem Nutzertest herauszufinden.
Bei normalen Webseiten. Nicht hingegen bei SPAs, denn das wurde ein komplettes Neuladen der SPA bedeuten, während der Selflink lediglich die Daten neu holen muss, oder was auch immer.
dedlfix.
@@dedlfix
Nicht hingegen bei SPAs, denn das wurde ein komplettes Neuladen der SPA bedeuten
Wenn die SPA schnell und billig implementiert wurde, ja.
Wenn die SPA gut implementiert wurde, dann nicht.
LLAP 🖖
Tach!
Auf der Kehrseite hat man mit
readfilekeinen single point of change mehr. Wenn man das Include ändert und es dann doch PHP-Code enthält, müsste man zusätzlich die Einbindung vonreadfileaufinclude(o.ä.) ändern – und das auf allen Seiten.
Ja, so ist das. Will man was ändern, muss man was ändern. Manchmal auch etwas mehr.
Das sollte dafür sprechen, gleich
include(o.ä.) zu verwenden, oder?
YAGNI oder: Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen. Irgendetwas im Hinblick auf die Richtigkeit in der Zukunft machen zu wollen, hat das Problem, dass man selten weiß, was in der Zukunft als richtig erachtet werden wird.
Nach Myrphys Gesetz wird alles andere eintreten, nur nicht Punkt 2.
dedlfix.
@@dedlfix
Das sollte dafür sprechen, gleich
include(o.ä.) zu verwenden, oder?YAGNI oder: Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen. Irgendetwas im Hinblick auf die Richtigkeit in der Zukunft machen zu wollen, hat das Problem, dass man selten weiß, was in der Zukunft als richtig erachtet werden wird.
- Es wird keine Änderung geben und die Arbeit für die Zukunft war umsonst.
- Es wird eine Änderung geben und dafür war die Vorarbeit richtig.
- Es wird eine Änderung geben, aber weder die gegenwärtig notwendige Version noch die für die Zukunft geplante lässt sich unverändert verwenden.
Nach Myrphys Gesetz wird alles andere eintreten, nur nicht Punkt 2.
Ich denke, in einigen Fällen lässt sich durch etwas Überlegung im Vorfeld Murphy ein Schnippchen schlagen.
Diesen halte ich für einen solchen Fall.
LLAP 🖖
Hallo und guten Morgen,
<nav class="nav"> <ul> <li><a href="#home">Home</a></li> <li><a href="#seite1">Seite 1</a></li> <li><a href="#seite2">Seite 2</a></li> <li><a href="#seite3">Seite 3</a></li> ...damit schaffe ich es auch dass die URL "meineseite.de/index.html#seite2" aufgerufen werden soll, jedoch bleibe ich immer auf meiner index Seite hängen, da ich nicht weiß wie ich jetzt #seite2 anlegen soll...
Die URLs der Links, die Du dort oben abbildest, sind alle gleich. Sie zeigen immer auf das im Browser gerade aktuelle Dokument. Durch das # hängst Du dann browserseitig an die URL/URi ein sogenanntes Fragment an. Damit kann man, nachdem das Dokument an den Browser übertragen wurde, innerhalb des Dokumentes navigieren.
Wenn Du unterschiedliche Ressourcen adressieren willst, musst Du auch die URL/URi ändern, also den Teil, der VOR dem #seiteX
Grüße
TS
Hallo TS,
Durch das # hängst Du dann browserseitig an die URL/URi ein sogenanntes Fragment an. Damit kann man, nachdem das Dokument an den Browser übertragen wurde, innerhalb des Dokumentes navigieren.
Wenn Du unterschiedliche Ressourcen adressieren willst, musst Du auch die URL/URi ändern, also den Teil, der VOR dem #seiteX
Der Aufbau eines URI ist scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]. Damit gehört auch das Fragment dazu.
Bis demnächst
Matthias
Hallo und guten Morgen,
Wenn Du unterschiedliche Ressourcen adressieren willst, musst Du auch die URL/URi ändern, also den Teil, der VOR dem #seiteX
Der Aufbau eines URI ist
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]. Damit gehört auch das Fragment dazu.
Das Fragment wird aber beim Request nicht mit übertragen vom Browser an den Server. Nur DARUM ging es doch in erster Linie. Nur das Fragment (das Gegenstück zum Anker) zu ändern, hat also auf dem Server beim Request gar keinen Einfluss.
Wenn chrisproud eine serverseitige Skriptsprache zur Verfügung hat, kann er/sie sich das auch ansehen. Das ist mMn immer ganz hilfreiche, sich erst einmal Übersicht über die Zusammenhänge zu verschaffen.
Grüße
TS
Hallo TS,
Wenn Du unterschiedliche Ressourcen adressieren willst, musst Du auch die URL/URi ändern, also den Teil, der VOR dem #seiteX
Der Aufbau eines URI ist
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]. Damit gehört auch das Fragment dazu.Das Fragment wird aber beim Request nicht mit übertragen vom Browser an den Server. Nur DARUM ging es doch in erster Linie. Nur das Fragment (das Gegenstück zum Anker) zu ändern, hat also auf dem Server beim Request gar keinen Einfluss.
Mir ging es darum, zu klären, dass ein URI eben nicht der Teil vor dem # ist.
Bis demnächst
Matthias
Vielen Dank fürs lesen - bin natürlich auch offen für weitere Vorschläge eine Navigation aufzubauen :)
Idealerweise liegt die Konfiguration der gesamten Website im Haupspeicher. So kann der Prozess, der zum Ausliefern des zum URL gehörigen Inhaltes zuständig ist, anhand der Konfiguration auch das Menu, etwaige BreadCrumbs und weitere Dinge ausgeben.
Das Alles lässt sich über Klassen und deren Methoden bestens organisieren. Wenn Du hier z.B. in den Quelltext guckst, siehst Du bereits im Kopfbereich der Seite zwei Angaben
<!-- class: DBResponse -->
<!-- interface: source -->
wo praktisch für den URL konfigurierte Attribute ins Template gerendert werden (für's Debugging und Teamarbeit ganz nützlich). Gleichermaßen zeigt <link href="/upload" rel="index"> auf denjenigen URL der als Index zuständig ist, in der Konfiguration steht hierzu parent=/upload. Die Konfiguration zum URL /upload schließlich sieht so aus:
[/upload]
title=File Upload - Dateien via Browser hochladen
descr=Ein oft gefragtes Thema sind Scripts zum Thema FileUpload
isa=folder
class=Folder
short=Upload
breadcrumb=/blog /web /upload
parent=/web
womit das Response-Objekt ein Navigations-Menu mit BradCrumbs macht.
Machs besser ;)
Hallo pl,
Vielen Dank fürs lesen - bin natürlich auch offen für weitere Vorschläge eine Navigation aufzubauen :)
Machs besser ;)
Das hilft dem Chrisproud so ziemlich genau überhaupt nichts.
Bis demnächst
Matthias
Vielen Dank fürs lesen - bin natürlich auch offen für weitere Vorschläge eine Navigation aufzubauen :)
Machs besser ;)
Das hilft dem Chrisproud so ziemlich genau überhaupt nichts.
Wie kommst Du denn darauf? Immerhin hat sich das von mir beschriebene Verfahren, die Navigation anhand der Konfiguration dynamisch zu erzeugen, seit mehr als 15 Jahren auf all meinen Domänen bewährt.
Feilich wird es ihm nichts nützen, wenn er diese Idee ungesehen in die Tonne tritt. Das eigentliche Menu übrigens wird bei mir über ein Template erzeugt, responsive isses auch und sämtliche Domänen nutzen einunddieselbe Methode -- also keine CodeRedundanzen.
MfG
@@pl
Das hilft dem Chrisproud so ziemlich genau überhaupt nichts.
Wie kommst Du denn darauf? Immerhin hat sich das von mir beschriebene Verfahren, die Navigation anhand der Konfiguration dynamisch zu erzeugen, seit mehr als 15 Jahren auf all meinen Domänen bewährt.
Du erkennst den Widerspruch? Um es dir etwas leichter zu machen, habe ich ihn leicht hervorgehoben.
responsive isses auch
Das hat mit serverseitiger Technik exakt was zu tun?
LLAP 🖖
Hallo,
habe ich ihn leicht hervorgehoben.
hervorgehoben? nö, du hast für Browser, die das umsetzen, die Schriftgröße erhöht. Zum Hervorheben, bzw. Emphasizen, gibt es das em-Element!1elf
Gruß
Kalk
@@Tabellenkalk
habe ich ihn leicht hervorgehoben.
hervorgehoben? nö, du hast für Browser, die das umsetzen, die Schriftgröße erhöht. Zum Hervorheben, bzw. Emphasizen, gibt es das em-Element!1elf
Und zum Leicht-Hervorheben gibt es … — strong!1zwölf
LLAP 🖖
Hallo,
Und zum Leicht-Hervorheben gibt es … —
strong!1zwölf
ne, das hast du jetzt einen Übersetzungsfehler drin. Für's Leicht-Hervorheben müsste man erst noch ein Weak-Element einführen!1drölf
Gruß
Kalk
@@pl
Das hilft dem Chrisproud so ziemlich genau überhaupt nichts.
Wie kommst Du denn darauf? Immerhin hat sich das von mir beschriebene Verfahren, die Navigation anhand der Konfiguration dynamisch zu erzeugen, seit mehr als 15 Jahren auf all meinen Domänen bewährt.
Du erkennst den Widerspruch? Um es dir etwas leichter zu machen, habe ich ihn leicht hervorgehoben.
Daran ist nichts Widersprüchliches. Ich empfehle eine bewährte Technik.
responsive isses auch
Das hat mit serverseitiger Technik exakt was zu tun?
Was an dem Wort 'Template' hast Du nicht verstanden!?
Daran ist nichts Widersprüchliches. Ich empfehle eine bewährte Technik.
Eine Technik, die seit 15 Jahren auf einer handvoll privater Homepages läuft, ist nicht bewährt. Sie musste sich ja auch noch nicht bewähren. Wenn man sich die regelmäßige Kritik an deiner Arbeit hier zu Gemüte führt und mit deiner Ignoranz paart, dann bleibt nicht viel übrig von deiner Reputation.
Das hilft dem Chrisproud so ziemlich genau überhaupt nichts.
Das entscheidest nicht Du sondern der OP entscheidet, ob er meinen Vorschlag aufgreift.
Hallo,
der OP entscheidet
Ob der sich hier wohl nochmal meldet?
Gruß
Kalk
Hallo,
der OP entscheidet
Ob der sich hier wohl nochmal meldet?
Nachdem sogenannte Fachleute über mein geistiges Eigentum, was ich hier freizügig zur Verfügung stelle, ziemlch unsachlich hergefallen sind, ist das wirklich eine spannende Frage.
@@pl
Nachdem sogenannte Fachleute über mein geistiges Eigentum, was ich hier freizügig zur Verfügung stelle, ziemlch unsachlich hergefallen sind, ist das wirklich eine spannende Frage.
Kann das sein, dass die Adjektive rotiert sind und du sagen wolltest:
Nachdem spannende Fachleute über mein sogenanntes Eigentum, was ich hier geistig zur Verfügung stelle, ziemlch freizügig hergefallen sind, ist das wirklich eine unsachliche Frage.
LLAP 🖖
Hallo,
der OP entscheidet
Ob der sich hier wohl nochmal meldet?
Nachdem sogenannte Fachleute über mein geistiges Eigentum, was ich hier freizügig zur Verfügung stelle, ziemlch unsachlich hergefallen sind, ist das wirklich eine spannende Frage.
Die sich insbesondere die Forumsbetreiber mal ernsthaft stellen sollten.
Nachdem sogenannte Fachleute über mein geistiges Eigentum, was ich hier freizügig zur Verfügung stelle, ziemlch unsachlich hergefallen sind, ist das wirklich eine spannende Frage.
Die sich insbesondere die Forumsbetreiber mal ernsthaft stellen sollten:
Ein paar Tipps, wie man sich wirkungsvoll mit Kritik auseinandersetzen kann:
[ ] Sich selbst bemitleiden
[ ] Mit abfälligen Bemerkungen über die Kritiker das eigene Ego pushen
[ ] Mit Kauderwelsch und nebulösen Aussagen den Leser verwirren
[ ] Mit DDR-Anekdoten vom Thema ablenken
[ ] Mit Perl-Beispielen kontern
[x] Sich reflektiert mit dem Inhalt beschäftigen
Mit fünf der sechs Punkte hast du es bereits versucht.