nicht angemeldet
Vorschlag fuer Feature-Artikel zu Includes
0 0 0 0 0 0 0 0 0
Vorschlag fuer Feature-Artikel zu Includes
Hallo zusammen,
Was lange waehrt, wird (hoffentlich) endlich gut...
Im Oktober </archiv/2003/10/59514/#m336524> hatte ich angekuendigt,
dass ich einen Artikel zu "Includes" plane. Nun ist er da - noch nicht ganz
vollstaendig, aber dafuer gibt es ja Euch ;-)
http://www.tiptom.ch/homepage/includes.html
Ich moechte den Artikel gerne fuer den Self-Raum als Feature-Artikel
zur Verfuegung stellen, wenn der "Inner Circle" damit einverstanden ist.
(Die Kategorie "Projektverwaltung" waere IMHO am besten geeignet.)
http://aktuell.de.selfhtml.org/artikel/beitrag.htm habe ich gelesen.
Warum ich mich nicht direkt an die dort angegebene E-Mail-Adresse wende:
1. Ich waere froh um kritische Durchsicht des Artikels und Kommentare
sowie einige Ergaenzungen, z.B. zu GoLive und Perl.
2. Ich habe noch einige Fragen zur Form eines Feature-Artikels
bzw. zu den Freiheiten, die man als Autor trotz der "Schablone" hat.
1. Inhaltliche Fragen
---------------------
Sprache: Sind die Saetze verstaendlich und Web-gerecht?
Was wuerdet Ihr anders formulieren?
Aufbau/Erklaerungen: Sind der Aufbau und die Erklaerungen
nachvollziehbar und verstaendlich?
Meine Wissensluecken:
1. An HTML-Editoren erwaehne ich Phase 5, Macromedia Dreamweaver,
Adobe GoLive und MS Frontpage.
Zu GoLive haette ich gerne noch ein paar Stichworte/Links,
wie man dort so etwas wie Includes oder Templates einsetzen kann.
Auch bei Frontpage koennte ich noch einige Infos brauchen.
2. Bei den serverseitigen Programmiersprachen sage ich bis jetzt
kein Wort zu Perl. Erstens kenne ich mich damit zuwenig aus,
zweitens bezweifle ich, dass es geeignet ist fuer blosse Includes
(AFAIK existiert keine Syntax, mit der man Perl-Code mitten
in den HTML-Code einstreuen kann wie z.B. PHP oder SSI),
und drittens befuerchte ich, dass dann staendig Newbies
bei mir (als Autor) oder hier im Forum nachfragen, warum ihre
Perl-Skripten nicht funktionieren, und man ihnen dann ASCII-Upload,
CHMOD und den ganzen Krempel 1000 mal erklaeren muss...
Im Ernst: Falls jemand denkt, dass auch Perl als "Include-Sprache"
geeignet ist und mir den notwendigen Code und/oder Links zu
guten Tutorials schickt, ergaenze ich den Artikel gerne...
HTML: Ich habe mir Muehe gegeben, die Dinge semantisch korrekt
auszuzeichnen. Dennoch bin ich dankbar fuer Hinweise,
was ich dort noch besser machen koennte.
(Ausnahme: Gedankenstriche werde ich nicht als &emdash; oder
was es sonst noch gibt codieren. Die "falschen Freunde" sind
das stabilste, was es gibt, und ich werde mich nicht ueberzeugen
lassen, irgendwelchen Entities zu nehmen, die in alten Browsern
"ausgschrieben" dargestellt werden...)
2. Formale Fragen
-----------------
Ich wuerde den Artikel natuerlich in die Self-Schablone quetschen
sowie die Faehnchen vor den Links u.s.w. ergaenzen.
Ich moechte auch gleich im Inhaltsverzeichnis am Anfang der Seite
Sprunglinks auf H3-Ueberschriften machen, und hoffe, dass das OK ist.
Fuer groessere Bloecke mit Quellcode ist folgendes vorgeschrieben:
<table width="100%" cellpadding=10><tr><td class="xmpcode" bgcolor="#ffffe0"><pre>
<html>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren -->
</html>
</pre></td></tr></table>
Ich finde diesen Quellcode graesslich:
- Voellig ueberfluessige Tabelle
- presentational Markup (width, cellpadding, bgcolor)
- keine logische Auszeichnung als Programmcode.
Folgendes faende ich viel sauberer:
<p class="xmpcode"><code>
<html><br>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren --><br>
</html><br>
</code></p>
Des weiteren finde ich, dass das vorgeschriebene Layout ja
vor allem fuer Screen vorgesehen ist (trotz pt-Schriftgroessen:-).
Ich verwende gerne ein separates Stylesheet fuer Print.
Im Screen-Stylesheet blende ich die URLs von Links aus,
im Print-Stylesheet (und ohne CSS) lasse ich sie anzeigen.
screen.css:
.printonly { display:none; }
HTML:
<a href="http://selfhtml.teamone.de/cgiperl/intro/ssi.htm">SelfHTML-Artikel zu SSI<span class="printonly"> - http://selfhtml.teamone.de/cgiperl/intro/ssi.htm</span></a>
Koennte (d.h. "duerfte") ich diese Methode auch in einem
Feature-Artikel verwenden? Also eigenes CSS einsetzen,
um die URLs auf dem Bildschirm auszublenden?
Koennte der Artikel auch in XHTML 1.0 Strict sein?
D.h. alles, was Layout ist, ins CSS verbannen,
voelliger Verzicht auf presentational Markup.
Die Links habe ich an den jeweiligen Stellen im Fliesstext eingebaut.
Eine extra Linkliste am Schluss scheint mir in diesem Fall nicht
sinnvoll/notwendig.
Gibt es dazu andere Meinungen?
Freundliche Gruesse,
Thomas
P.S. Ich werde den Artikel voraussichtlich in den naechsten Tagen
aufgrund der Diskussion hier laufend etwas ueberarbeiten.
Der "Original-Zustand" ist: http://www.tiptom.ch/homepage/includes0.html
-
Moin Moin !
Flüchtigkeitsfehler:
In "Active Server Pages (ASP)" fehlt etwas: "Die Syntax in >>> <<< gleicht der von SSI auf dem Apache-Webserver:"
In "Missverständisse und Anfänger-Fragen" würde ich Bezug groß schreiben, schlag besser mal im Duden nach: "Häufige Missverständnisse/Newbie-Fragen in >>>bezug<<< auf Includes:"
Unter "Serverseitige Lösungen" fehlt im Text "Etwas völlig anderes ist der Begriff "DHTML"" der Link auf das DHTML-Kapitel von SelfHTML.
Meiner Meinung nach benutzt Du zu viel "ss" und zu wenig "ß", aber auch da solltest Du mal im Duden nachsehen.
Inhalt:
Wann setzt man welche Technik ein? Die Entscheidung, ob man serverseitige Tools oder HTML-Editoren einsetzt, hängt sicherlich auch davon ab, ob man serverseitige Tools einsetzen darf.
Setzt man HTML-Editoren ein, muß bei einer einzigen Änderung an einer zentralen Include-Datei unter Umständen die gesamte Webseite neu "berechnet" und hochgeladen werden. Das passiert bei serverseitigen Tools natürlich nicht.
Wenn man serverseitige Tools einsetzen will, welches soll man benutzen? Kriterien für die Auswahl (Performance, Serverbelastung, Flexibilität, Wartbarkeit, Portierbarkeit, ...)?
"Kann ich auch Seiten, die auf einem anderen Server liegen, als Include einbinden?" Soweit ok, es fehlt allerdings ein Hinweis auf die Sicherheit. Gerade diese Frage kommt im Forum immer wieder mal vor, hauptsächlich um PHP-Code von anderen Servern einzubinden. Wie gefährlich es sein kann, Code von fremden Servern ohne weitere Prüfungen auszuführen, wurde im Forum oft genug diskutiert.
In "SSI - Server Side Includes" schreibst Du "Meist funktionieren sie automatisch in Dateien mit der Endigung .shtml, bei manchen Server-Konfigurationen auch bei Dateien auf .html." SuSE konfiguriert(e) den Apachen so, evtl. auch andere. Leider hat dies einige üble Seiteneffekte, die Du nicht erwähnst: Der Apache muß *jede* ausgelieferte HTML-Seite parsen, auch wenn das gar nicht notwendig ist. Das kostet Leistung. Die Trennung in *.html und *.shtml reduziert die unnötige Last. In "alten Zeiten" gab es den X-Bit-Hack (siehe Apache-Doku, existiert sowohl in 1.3 als auch in 2.0), der anhand des Executable-Bits der Datei entschied, ob die Datei stumpf ausgeliefert oder geparst wurde. Das ist - wie der Name schon sagt - ein Hack, den man besser nicht benutzt.
In "Weitere serverseitige Programmiersprachen" schreibst Du zu ColdFusion "Cold Fusion Markup Language (CFML) ist eine Technologie von Macromedia, die auf >>>speziell ausgerüsteten Webservern<<< läuft." Diese "spezielle Ausrüstung" ist eine Installation von ColdFusion, das sich ähnlich wie PHP in den Webserver einhängt (soweit ich weiß, nur in IIS und Netscape / iPlanet).
Formulierungen / Ausdruck:
"Seitenbastler" in "Includes als Frames-Ersatz" ist abwertend, "Newbie" kann ebenfalls als abwertend empfunden werden.
In "Missverständisse und Anfänger-Fragen" schreibst Du dreimal ">>>kriegt nicht mit<<<", da ist "merkt nicht", "kann nicht unterscheiden", ö.ä. besser.
In "Beispiel: Fusszeile" schreibst Du als letztes Codebeispiel:
<!-- Ende des Inhalts -->
<!-- Platzhalter/Befehl für fusszeile.inc -->
</body>
</html>Weil die Syntax für den Include-Befehl je nach Technik sehr unterschiedlich ist, würde ich das anders darstellen:
<!-- Ende des Inhalts -->
*** Befehl um fusszeile.inc einzubinden ***
</body>
</html>Die Zeile "*** Befehl um fusszeile.inc einzubinden ***" würde ich andersfarbig und/oder kursiv und/oder in einer anderen Schriftart darstellen.
In "Weitere serverseitige Programmiersprachen" schreibst Du ">>>Offenbar<<< gilt für Includes folgende Syntax:". Du bist Dir also nicht sicher, ob diese Syntax richtig ist? Warum liest Du dann nicht in dem von Dir angegebenen Referenz-Link nach?
- Bei den serverseitigen Programmiersprachen sage ich bis jetzt
kein Wort zu Perl. Erstens kenne ich mich damit zuwenig aus,
zweitens bezweifle ich, dass es geeignet ist fuer blosse Includes
(AFAIK existiert keine Syntax, mit der man Perl-Code mitten
in den HTML-Code einstreuen kann wie z.B. PHP oder SSI),
Es gibt diverse Techniken, um mit Perl HTML zu erzeugen, z.B. mit embperl, entweder eingebunden in mod_perl (schneller) oder in einem Perl-CGI.
und drittens befuerchte ich, dass dann staendig Newbies
bei mir (als Autor) oder hier im Forum nachfragen, warum ihre
Perl-Skripten nicht funktionieren, und man ihnen dann ASCII-Upload,
CHMOD und den ganzen Krempel 1000 mal erklaeren muss...Das könntest Du gleich im Artikel ein für alle mal klären, das hätte außerdem den angenehmen Seiteneffekt, daß solche Fragen im Forum schlicht mit einem Link auf Deinen Artikel "abgewürgt" werden können. Bleibt anzumerken, daß die großen "Volkshoster" für billige Webpräsenzen in der Regel kein Perl anbieten, weil es zu mächtig ist. Wenn überhaupt, dann nur für CGIs, nicht als mod_perl. PHP läßt sich wohl leichter soweit kastrieren, daß ein böser User nicht gleich den ganzen Server lahmlegt. Auf dedizierten oder virtuellen Servern (nicht zu verwechseln mit Vitual Hosts; zu erkennen am root-Zugriff) sieht die Sache schon anders aus.
Im Ernst: Falls jemand denkt, dass auch Perl als "Include-Sprache"
geeignet ist und mir den notwendigen Code und/oder Links zu
guten Tutorials schickt, ergaenze ich den Artikel gerne...Eine schnelle Google-Suche liefert u.a. http://www.quiptime.de/site/perl/embperl/embperl_faq.php und http://perl.apache.org/embperl/. Embperl funktioniert auch offline, quasi als Konkurrenz zu HTML-Editoren.
Fuer groessere Bloecke mit Quellcode ist folgendes vorgeschrieben:
<table width="100%" cellpadding=10><tr><td class="xmpcode" bgcolor="#ffffe0"><pre>
<html>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren -->
</html>
</pre></td></tr></table>Ich finde diesen Quellcode graesslich:
- Voellig ueberfluessige Tabelle
- presentational Markup (width, cellpadding, bgcolor)
Richtig.
- keine logische Auszeichnung als Programmcode.
Doch: pre
Folgendes faende ich viel sauberer:
<p class="xmpcode"><code>
<html><br>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren --><br>
</html><br>
</code></p>Meine Meinung: Nimm <pre> statt <code>+<br>, dafür ist es IMHO da. Du kannst gerne eine Klasse zuweisen, um es zu stylen.
Allerdings bin ich nicht für die Artikel verantwortlich, da sollen andere einen verbindlichen Kommentar abgeben.
Die Links habe ich an den jeweiligen Stellen im Fliesstext eingebaut.
Eine extra Linkliste am Schluss scheint mir in diesem Fall nicht
sinnvoll/notwendig.
Gibt es dazu andere Meinungen?Ja. Es ist SelfHTML-Stil, und es erlaubt den schnellen Überblick über Seiten mit weiteren Informationen, ähnlich wie eine Quellenangabe in wissenschaftlichen Texten.
Alexander
--
Nein, ich beantworte keine Fragen per eMail. Dafür ist das Forum da.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Meiner Meinung nach benutzt Du zu viel "ss" und zu wenig "ß", aber auch da solltest Du mal im Duden nachsehen.
Alexander,
Thomas weist das Dokument als xml:lang="de-ch" lang="de-ch" aus.Von einem Schweizer zu verlangen, ß zu benutzen, wäre wie von einem Baden-Württemberger zu verlangen, hochdeutsch zu sprechen. ;-)
Gunnar--
Good results come from experience; and experience comes from bad results. -
Hallo Alexander,
Danke fuer das ausfuehrliche und konstruktive Feedback!
Dank auch an die andern - ich muss gleich weg, werde aber
später noch auf Eure Postings eingehen.Erste Änderungen habe ich bereits gemacht.
In "Missverständisse und Anfänger-Fragen" würde ich Bezug groß schreiben, schlag besser mal im Duden nach: "Häufige Missverständnisse/Newbie-Fragen in >>>bezug<<< auf Includes:"
Meiner Meinung nach benutzt Du zu viel "ss" und zu wenig "ß", aber auch da solltest Du mal im Duden nachsehen.Ich nehme mir die Freiheit, die herkoemmliche deutsche Rechtschreibung
zu verwenden. Und dort schreibt man gemaess Duden "in bezug auf".
Als Schweizer verwende ich Euren komischen Buchstaben "sz" nie - er
kommt auf meiner Tastatur nicht vor, und selbst wenn, wuerde ich ihn
nie im Leben verwenden. ;-)Unter "Serverseitige Lösungen" fehlt im Text "Etwas völlig anderes ist der Begriff "DHTML"" der Link auf das DHTML-Kapitel von SelfHTML.
Danke, gemacht.
Wann setzt man welche Technik ein? Die Entscheidung, ob man serverseitige Tools oder HTML-Editoren einsetzt, hängt sicherlich auch davon ab, ob man serverseitige Tools einsetzen darf.
Wenn man serverseitige Tools einsetzen will, welches soll man benutzen? Kriterien für die Auswahl (Performance, Serverbelastung, Flexibilität, Wartbarkeit, Portierbarkeit, ...)?Gute Fragen!
Das kann ich wohl kaum umfassend darstellen, aber ich werde
noch etwas in der Richtung ergaenzen.[...] Wie gefährlich es sein kann, Code von fremden Servern ohne weitere Prüfungen auszuführen, wurde im Forum oft genug diskutiert.
Stimmt, danke, ich habe entsprechende Hinweise hingemacht.
http://www.tiptom.ch/homepage/includes.html#php[SSI, .html/.shtml, Serverlast]
Habe einen Hinweis gemacht.
"Seitenbastler" in "Includes als Frames-Ersatz" ist abwertend,
Bewusst. (Nehme mir die Freiheit, auch so zu werten.)
Mal gucken, was der "Inner Circle" dazu meint... ;-)
(@Stonie: Danke fuer's Mail, werde es Euch schon noch
direkt schicken!)In "Missverständisse und Anfänger-Fragen" schreibst Du dreimal ">>>kriegt nicht mit<<<", da ist "merkt nicht", "kann nicht unterscheiden", ö.ä. besser.
Mach ich noch.
<!-- Ende des Inhalts -->
*** Befehl um fusszeile.inc einzubinden ***Stimmt. Gemacht.
Es gibt diverse Techniken, um mit Perl HTML zu erzeugen, z.B. mit embperl, entweder eingebunden in mod_perl (schneller) oder in einem Perl-CGI.
Danke. Wusste nichts von embperl und konnte somit auch nicht googeln... ;-)
Guck den neuen Abschnitt doch mal an:
http://www.tiptom.ch/homepage/includes.html#embperl
Ins Detail moechte ich dort nicht gehen, weil ich fuer diese
Technologie viele Huerden/Probleme sehe und weil sie
wohl nur selten eingesetzt wird.- keine logische Auszeichnung als Programmcode.
Doch: pre
<pre> ist presentational Markup, sagt nur, dass
Zeilenumbrueche und diktengleiche Schrift verwendet
werden soll.
<code> ist semantisches Markup.Gruesse,
Thomas
der sich spaeter wieder meldet... - keine logische Auszeichnung als Programmcode.
- Bei den serverseitigen Programmiersprachen sage ich bis jetzt
-
Hallo Thomas,
Ich wuerde den Artikel natuerlich in die Self-Schablone quetschen
sowie die Faehnchen vor den Links u.s.w. ergaenzen.Prima. :)
Ich moechte auch gleich im Inhaltsverzeichnis am Anfang der Seite
Sprunglinks auf H3-Ueberschriften machen, und hoffe, dass das OK ist.Das ist - sagen wir mal - ungewöhnlich. In diesem Fall würde ich jedoch die Links auf <h3> etwas einrücken, damit eine Struktur erkennbar ist.
Ich finde diesen Quellcode graesslich:
- Voellig ueberfluessige Tabelle
- presentational Markup (width, cellpadding, bgcolor)
- keine logische Auszeichnung als Programmcode.
Siehe ganz unten.
(trotz pt-Schriftgroessen:-).
pt-Schriftgrößen? Welches Stylesheet hast Du? Bei mir sind hier 13.4px angegeben.
Kennst Du http://aktuell.de.selfhtml.org/sonst/layoutvorgaben.htm?
[Eigenes CSS, bei Bildschrimdarstellung best. Dinge ausblenden]
Koennte (d.h. "duerfte") ich diese Methode auch in einem
Feature-Artikel verwenden?Ich denke, da spricht nichts dagegen. Aber ich würde an Deiner Stelle lieber das Original-Bildschirmstylesheet einbinden und dann im Head-Bereich noch ein <style>-Element einfügen.
Koennte der Artikel auch in XHTML 1.0 Strict sein?
D.h. alles, was Layout ist, ins CSS verbannen,
voelliger Verzicht auf presentational Markup.Das Problem ist folgendes: Es gibt im Moment nunmal die Layoutvorgaben. Diese sind nicht nur dazu da, das Aussehen zu vereinheitlichen, sondern auch den Code. Konkret heißt das, dass es eigentlich nicht so toll wäre, uns jedes Mal, wenn wir eine Seite bearbeiten müssen, uns erst in den dort verwendeten Code einarbeiten müssten.
Es gab ja vor kurzem nochmal einen Layoutwettbewerb zu SELFHTML - und dort gab es durchaus brauchbare Lösungen mit "besserem" Markup. Das wird sicherlich irgendwann kommen.
Von daher: Wenn es Dir nicht zu sehr etwas ausmacht, mal 'presentational Markup' zu schreiben, wäre es nett, wenn Du Dich an die Layoutrichtlinien halten könntest.
Ich werde die Diskussion aber mal intern anstoßen, mal sehen, was die anderen dazu sagen.
Viele Grüße,
Christian-
Hallo Christian,
Danke fuer die Kommentare und den Link zu den Vorgaben.
(trotz pt-Schriftgroessen:-).
pt-Schriftgrößen? Welches Stylesheet hast Du? Bei mir sind hier 13.4px angegeben.Ich meine die Datei selfhtml.css im ZIP-Archiv (artikel.zip), das zuunterst
auf http://aktuell.de.selfhtml.org/artikel/beitrag.htm#a3 verlinkt ist.
Ausschnitte daraus:h1 { font-size:18pt; }
h2 { font-size:16pt; }
h2.sh2 { font-size:16pt; }
h3,h3.xmp,h3.xpl,h3.inf,h3.tip,h3.akt { font-size:12pt; }
/* 11pt = 12 Punkt, Wert aenderbar */
^^^^^^^^^^^^^^^ ;-)Kennst Du http://aktuell.de.selfhtml.org/sonst/layoutvorgaben.htm?
Nein, hatte ich bisher nicht gesehen (allerdings auch
nicht aktiv gesucht ;-)
Vielleicht sollte man es auch noch hier verlinken:
http://aktuell.de.selfhtml.org/artikel/beitrag.htm#a3[Eigenes CSS, bei Bildschrimdarstellung best. Dinge ausblenden]
Ich denke, da spricht nichts dagegen. Aber ich würde an Deiner Stelle lieber das Original-Bildschirmstylesheet einbinden und dann im Head-Bereich noch ein <style>-Element einfügen.Genau das hatte ich auch vor. ;-)
Ich habe ja relativ viele Links.
Vermutlich werde ich als letzten Abschnitt
die Links gebuendelt nochmals auflisten,
und nur dort die URL fuer den Ausdruck
angeben (die ich mit dem Screen-CSS
verstecke), aber nicht bei den Links im Fliesstext.[...] Es gibt im Moment nunmal die Layoutvorgaben. [...]
Von daher: Wenn es Dir nicht zu sehr etwas ausmacht, mal 'presentational Markup' zu schreiben, wäre es nett, wenn Du Dich an die Layoutrichtlinien halten könntest.Das leuchtet mir ein. Ich werde es tun.
Inklusive HTML 4.01 Transitional, Faehnchen und allem, was dazugehoert.Ich werde die Diskussion aber mal intern anstoßen, mal sehen, was die anderen dazu sagen.
Ja, nimmt mich wunder!
Es geht mir halt schon ein wenig gegen den Strich,
presentational Markup zu verwenden und sogar
IMHO falsches Markup (<pre> statt <code>) zu
schreiben, bloss weil es eine alte Vorgabe so will...Freundliche Gruesse,
Thomas
-
Moin!
Es geht mir halt schon ein wenig gegen den Strich,
presentational Markup zu verwenden und sogar
IMHO falsches Markup (<pre> statt <code>) zu
schreiben, bloss weil es eine alte Vorgabe so will...Ob alt oder nicht, ob überkommen, falsch oder nicht wünschenswert: Es ist nun mal die Vorgabe.
Folgendes Argument wird dich vielleicht überzeugen: Weil die Dokumente sicherlich irgendwann alle mal auf irgendetwas besseres (XML o.ä.) umgestellt werden, und dann viel Suchen/Ersetzen oder XML-Transformieren notwendig sein wird, wäre es außerordentlich schädlich, wenn du jetzt mit deinem Artikel aus der Reihe tanzen würdest. Weil der dann nämlich bei der Umstellung mit Sicherheit eine Sonderbehandlung kriegen müßte.
Ok, ein Artikel ist vielleicht noch machbar - aber übermorgen kommt der nächste Autor und backt wieder seine eigenen Brötchen - und findet auch wieder tolle Argumente, warum er gewisse Dinge nicht schön findet und seine Ersatzlösung besser ist.
Deshalb ist in meinen Augen jegliches Abweichen von den Vorgaben absolut verboten.
Was dein Druckstylesheet bzw. die Screendarstellung angeht: Auch das ist in meinen Augen ein unzulässiges Abweichen von der Norm. In jeder Seite wird das SelfHTML-CSS eingebunden. Das steht fest und unverrückbar da. Die Einbindung eines Druckstylesheets ist nicht vorgesehen (kommt sicherlich mit der Umstellung der Seiten - diese Umstellung allerdings noch nicht so bald). Also ist deine gut gemeinte Lösung mit den URLs in den Links, die auf dem Bildschirm nicht angezeigt werden, eben auch wieder eine Speziallösung dieser einen Seite, die beim automatischen Konvertieren zu Extraarbeit führen wird.
Als Diskussionsanregung ist das ja vielleicht ganz nett. Allerdings wäre mein Standpunkt dazu dann eher, dass es, wenn überhaupt, dann ins Druckstylesheet gehören würde:
a:link:after {content:"(URL: "attr(href)")" }
Oder so ähnlich. Kann man sich mit fähigen Browsern auch heute schon in sein individuelles Druckstylesheet packen und davon auf allen Seiten profitieren.
Kurz zusammengefaßt: Deine Kritik an der rückständigen Auszeichnung der SelfHTML-Seiten ist zwar berechtigt, aber diese alte Struktur ist aufgrund der Menge an Dokumenten, die bereits existieren, absolut notwendig einzuhalten - damit überhaupt die Chance besteht, sie irgendwann einmal zu ändern.
Es wäre toll, wenn du deine Bedenken in dieser Hinsicht einfach ignorieren könntest. Manchmal ist man eben zu ekligen Dingen gezwungen.
- Sven Rautenberg
--
Die SelfHTML-Developer sagen Dankeschön für aktuell 20065,57 Euro Spendengelder!-
Hallo Sven,
Weil die Dokumente sicherlich irgendwann alle mal auf irgendetwas besseres (XML o.ä.) umgestellt werden, und dann viel Suchen/Ersetzen oder XML-Transformieren notwendig sein wird, wäre es außerordentlich schädlich, wenn du jetzt mit deinem Artikel aus der Reihe tanzen würdest.
Das leuchtet mir ein.
a:link:after {content:"(URL: "attr(href)")" }
Jaja. Das waere ideal.
Siehe auch den Teilthread at/wahsaga/u.s.w. [pref:t=67153&m=384235].Ich sehe aber auch ein, dass meine Idee fuer die Einheitlichkeit
und vor allem Transformierbarkeit nicht foerderlich waere,
und werde sie also fallen lassen.Manchmal ist man eben zu ekligen Dingen gezwungen.
Oh ja. Das ist unser Alltag im Webpublishing. :-(
Gruesse,
Thomas
--
In der Theorie sind Theorie und Praxis dasselbe.
In der Praxis sind sie verschieden...
-
-
-
Hallo Thomas,
ich bezeichne mich jetzt mal als Newbie und komme mit dem Artikel gar nicht zurecht.
Sofern ich den Umfang ersehen kann, hast du zuviel Thematik auf zu kleinem Raum mit zu wenig Informationen bereitgestellt.
Es ist sehr einfach, einen Featureratikel auf 75% Verweise zu bauen. Wo bleibt da deine eigene Arbeit? Ein Besuch bei Google liefert wahrscheinlich mehr Infos.
Entweder grenzt du die Thematik ein oder du baust alles noch aus.
Da wir dich im Forum als bissigen und kompetenten Kommentator kennen, wirst du diese Anregungen hoffentlich auch richtig werten.
MfG
André
--
ss:{ zu:) ls:& fo:) de:] va:) ch:{ sh:) n4:# rl:° br:& js:| ie:% fl:| mo:}
http://forum.de.selfhtml.org/archiv/2003/10/60651/#m341175-
Hallo Andre,
Auch Dir Danke fuer's Feedback.
ich bezeichne mich jetzt mal als Newbie und komme mit dem Artikel gar nicht zurecht.
Schade.
Ich habe den einleitenden Teil "Das Prinzip"
http://www.tiptom.ch/homepage/includes.html#prinzip
noch etwas umformuliert sowie das Beispiel mit der Fusszeile
http://www.tiptom.ch/homepage/includes.html#beispiel
noch um den vollstaendigen ("fertigen") HTML-Code ergaenzt.
Ich hoffe, das erleichtert Newbies das Verstehen des Prinzips.Zudem habe ich noch eine weitere Seite mit
"konkreten" Beispielen gemacht:
http://www.tiptom.ch/homepage/includes2.htmlSofern ich den Umfang ersehen kann, hast du zuviel Thematik auf zu kleinem Raum mit zu wenig Informationen bereitgestellt.
Was meinst Du mit "zuwenig Informationen"?
Es ist mir klar, dass ich hier zu einem breiten "Rundumschlag"
ausgeholt habe, aber ich denke, dass sich das Thema doch
im Rahmen _eines_ Artikels behandeln laesst.Ich hoffe, dass der allgemeine Teil dank den oben erwaehnten
Ergaenzungen nun umfassender und besser verständlich ist.Die einzelnen Technologien moechte ich absichtlich nicht
im Detail beschreiben, sondern bloss auf ihre Existenz hinweisen,
sie kurz beschreiben und dann Links zu den entsprechenden
Dokumentationen anbieten.Die tausenden von Seiten, die saemtliche SSI-Befehle auflisten,
finde ich ueberfluessig. Darum geht es mir ueberhaupt nicht.Es ist sehr einfach, einen Featureratikel auf 75% Verweise zu bauen. Wo bleibt da deine eigene Arbeit? Ein Besuch bei Google liefert wahrscheinlich mehr Infos.
Willst Du mich beleidigen?
Auch in der urspruenglichen Fassung hatte der Artikel
deutlich mehr als 25% Text, der aus meiner Hand stammte.
Text, an dem ich zum Teil lange rumformuliert hatte, bevor
ich ihn Euch zum Frass vorwarf... ;-)Und wenn Du mit Google eine gute deutschsprachige Seite
findest, die das Prinzip von Includes im allgemeinen gut
beschreibt und eventuell sogar systematisch die verschiedenen
Loesungen kurz nennt (inkl. Beispiele), dann lass es mich bitte wissen.Der einzige Artikel, den ich kenne, der ein bisschen in
die Richtung geht, ist der aus der dciwam-FAQ:
http://www.netandmore.de/faq/fom-serve/cache/1213.html
Lange Zeit geisterte dort das exotische Code-Beispiel
<!-- ps_include file="Contents" --><!-- /ps_include file="Contents" -->
fuer PageSpinner (einen HTML-Editor fuer Macs) als
"die" Loesung fuer Offline-Includes herum. Mittlerweile
haben sie immerhin ergaenzt, dass auch Phase 5 ein
Includes-Konzept hat.
Und die Syntaxen fuer SSI und PHP findet man auch
auf der Seite, wenn auch mit ellenlangen Diskussionen
betreffend Performance, Caching u.s.w.Fuer Newbies ist dieser Artikel als Einfuehrung
ins Thema "Includes" bzw. "Dynamische Webseiten"
noch viel weniger geeignet als mein bescheidener
Vorschlag...Beschreibungen von einzelnen Technologien, z.B. SSI,
gibt es zuhauf, aber einen Artikel, der das Includes-Konzept
grundsaetzlich erlaeutert, habe ich nicht gefunden.Entweder grenzt du die Thematik ein oder du baust alles noch aus.
Wie gesagt will ich nicht alles ausbauen.
Den allgemeinen Teil habe ich aber inzwischen erweitert.Die speziellen Themen (spezifische Loesungen)
moechte ich moeglichst knapp halten.Da wir dich im Forum als bissigen und kompetenten Kommentator kennen, wirst du diese Anregungen hoffentlich auch richtig werten.
Ich weiss nicht recht, was ich damit anfangen soll.
So richtig konstruktiv fand ich die Kritik leider nicht.Trotzdem danke!
Freundliche Gruesse,
Thomas
-
Hallo.
Und wenn Du mit Google eine gute deutschsprachige Seite
findest, die das Prinzip von Includes im allgemeinen gut
beschreibt und eventuell sogar systematisch die verschiedenen
Loesungen kurz nennt (inkl. Beispiele), dann lass es mich bitte wissen.Könntest du -- nur ein Vorschlag -- die Vor- und Nachteile sowie vielleicht die wesentlichen Syntax-Unterschiede auch tabellaarisch präsentieren? Ich zumindest mag Vergleiche nämlich besonders dann, wenn man alle wesentlichen Punkte als Stichworte auf einen Blick sieht.
MfG, at-
Hallo,
Könntest du -- nur ein Vorschlag -- die Vor- und Nachteile sowie vielleicht die wesentlichen Syntax-Unterschiede auch tabellaarisch präsentieren?
Ich hatte schon befuerchtet, dass so ein Vorschlag kommt;-)
Syntax-Uebersicht kann ich machen.
Was meinst Du mit dem Rest, also den Vor- und Nachteilen?
Serverseitige Includes vs. HTML-Editoren-Loesungen (Includes/Templates)?
Die serverseitigen Loesungen miteinander vergleichen?
Z.B. anhand der folgenden Punkte:
http://www.tiptom.ch/homepage/includes.html#tech_unterschiede(A) Aufwand, um die Technologie/Programmiersprache zu lernen.
(B) Qualitaet der online verfuegbaren Dokumentation/Tutorials u.s.w.
(C) Moeglichkeiten, Flexibilitaet.
(D) Wartbarkeit, Übersichtlichkeit des Codes.
(E) Verfuegbarkeit und Verbreitung
(=> Portierbarkeit, Grösse der Community).
(F) Serverbelastung und Performance.
(G) Sicherheit
(*) ...Ich selbst kenne mich eigentlich nur mit PHP gut aus.
Von SSI habe ich einigermassen Ahnung.
Bei den anderen Technologien wuerde ich es nicht wagen,
mich zu aeussern.
(Insbesondere Perl ist fuer mich ein rotes Tuch ;-)Hier meine Einschaetzung fuer PHP und SSI.
Fuer andere Meinungen und Ergaenzungen bin ich offen!PHP SSI
(A) + +
(B) +++ +++
(C) +++ +
(D) +++ +++
(E) ++ +++
(F) ? ?
(G) ? ?Freundliche Gruesse,
Thomas
-
Hallo.
Ich hatte schon befuerchtet, dass so ein Vorschlag kommt;-)
Sorry ;-)
Syntax-Uebersicht kann ich machen.
Prima.
Was meinst Du mit dem Rest, also den Vor- und Nachteilen?
In etwa genau das, was du jetzt noch einmal aufgeführt hattest.
Ich selbst kenne mich eigentlich nur mit PHP gut aus.
Von SSI habe ich einigermassen Ahnung.
Bei den anderen Technologien wuerde ich es nicht wagen,
mich zu aeussern.
(Insbesondere Perl ist fuer mich ein rotes Tuch ;-)Für mich sind dies alles bisher nur böhmische Dörfer. Aber wie sich dies durch deinen Artikel einschließlich seiner tabellarischen Übersicht ändern wird, wirst auch du jemanden finden, der deine Lücken zu füllen vermag :-)
MfG, at
-
-
-
-
-
Thomas,
(Etwas völlig anderes ist der Begriff "DHTML" - Dynamisches HTML; darunter versteht man die Kombination von HTML, CSS und JavaScript, also von Dingen, die den Browser/Client betreffen.)
CSS hat IMHO nicht zwingend mit dynamischem HTML zu tun.
<script language="php">
Eigenartige Syntax: In HTML verlangt das script-Element ein type-Attribut. Aber das hier kommt ja gar nicht beim Nutzer an, sollte also egal sein.
Gruß,
Gunnar -
Hallo!
Mag sein, dass ich meinen Ruf als Pedant weiter ausbaue, aber gerade in einem Artikel für Anfänger können Vereinfachungen und Verflachungen zu unerwünschten Ergebnissen führen.
http://www.tiptom.ch/homepage/includes0.html
"Includes" sind HTML-Bausteine, die an einer einzigen Stelle gespeichert sind, aber an mehreren Orten verwendet werden.Das ist durchaus nicht notwendig. Ich verwende beispielsweise wegen der beschränkten Möglichkeiten meines Hosting-Pakets einen SSI-»Zufallsgenerator«, der schlicht zu jeder Sekunde eine neue Datei lädt. Wegen der ebenfalls möglichen Direktlinks zu einzelnen Zitaten ist es jedoch nicht möglich, Teile in die SSI-Datei auszulagern und so ein paar Kilobyte zu sparen.
http://emmanuel.dammerer.at/jaegerstaetter/zufall
http://emmanuel.dammerer.at/jaegerstaetter/1Das Aktualisieren geschieht auf Webserver oder bereits auf dem Rechner des Autors.
Welches Aktualisieren? Das ist eine sehr schwammig Formulierung, über die sogar ich, der zumindest nicht Anfänger ist, lange nachdenken musste.
Das, was der Webserver an den Browser ausliefert, ist in jedem Fall eine fertige, vollständige HTML-Datei. Der Browser merkt nichts davon, dass die Seite Includes enthält.
Auch, wenn es meiner und vermutlich deiner Meinung nach unverantwortlich ist, Javascript-»Includes« zu verwenden, diese Möglichkeit zu leugnen, ist nicht sehr schlau.
Wichtig: Includes dürfen nicht vollständige HTML-Seiten sein, sondern nur Bausteine. Es wäre völlig falsch, eine vollständige HTML-Datei als Include in eine andere einzubetten. Denn somit hätte man im endgültigen Quelltext die Elemente [...] doppelt.
Verquere Logik, siehe mein Gegenbeispiel.
[DHTML]
Kombination von HTML, CSS und JavaScript, also von Dingen, die den Browser/Client betreffen.)Ich will nicht darauf hinweisen, dass Javascript theoretisch auch auf dem Server laufen kann, aber deine Definition von DHTML ist schlicht falsch, siehe auch andere Wortmeldungen dazu.
Bei kommerziellem Webspace sollte es meiner Meinung nach selbstverständlich sein, dass SSI, PHP oder andere serverseitige Programmiersprachen zur Verfügung stehen, und zwar in einer aktuellen Version.
Deine persönliche Meinung ist, pardon, irrelevant für diesen Artikel. Abgesehen davon, warum sollte jedes Angebot zwingend diese Möglichkeiten beinhalten? Nicht jeder benötigt so etwas.
Seien wir ehrlich - einer der meistgenannten Gründe, warum so viele Seitenbastler überhaupt Frames verwenden, ist Bequemlichkeit.
"Ich will doch nicht 100 Dateien ändern müssen, bloss weil eine neue Seite dazugekommen ist! [...]"
Diese Ausrede gilt ab sofort nicht mehr. Mit Includes muss man auch nur eine einzige Datei ändern, der Rest geschieht "von selbst".</p>Abgesehen davon, dass ich, als scharfer Kritiker des gesamten Frame-Konzeptes bekannt bin, akzeptiere ich, dass es diverse Anwendungsbereiche dafür gibt, wenn auch sehr beschränkt. Deine Polemik (»Seien wir ehrlich« - an wen richtest du dich denn eigentlich, an den Anfänger oder an Experten?) hat in einem Feature-Artikel nichts zu suchen, höchstens kannst du versuchen, sachlich auf die Probleme hinzuweisen.
Egal, ob die Navigation in einem <DIV>-Element, in einer Tabellenzelle oder einfach in einer Fusszeile plaziert ist - in allen Fällen reicht ein Include-Befehl/-Platzhalter an der Stelle, wo später die Navigation stehen soll.
Auch noch auf diese Diskussion willst du dich in deinem Artikel einlassen. Ich werde dich nicht daran hindern, bitte dich aber, das etwas fundierter zu tun. Ich beispielsweise rate dringend von <div> ab, ebenso wie von Tabellen. Von Frames sowieso.
mitkriegen
Ich respektiere und mag das schweizerische Hochdeutsch, weiß aber, dass dieser Ausdruck einfach nur Umgangssprache ist, der in einem technischen Artikel nicht adäquat ist und darüberhinaus verwirrend sein kann.
Ich liste nicht alle Fehler und offensichtliche Missverständnisse auf, da ich davon ausgehe, dass der Artikel so ohnehin unbrauchbar ist. Ich rate dringend davon ab, diesen Artikel als Feature-Artikel zu verwenden, tut mir leid.
emu
-
Hallo emu,
Danke fuer Dein differenziertes Feedback.
Viele der sprachlichen und inhaltlichen Punkte,
die Du kritisierst, habe ich inzwischen geaendert.Egal, ob die Navigation in einem <DIV>-Element, in einer Tabellenzelle oder einfach in einer Fusszeile plaziert ist - in allen Fällen reicht ein Include-Befehl/-Platzhalter an der Stelle, wo später die Navigation stehen soll.
Auch noch auf diese Diskussion willst du dich in deinem Artikel einlassen. Ich werde dich nicht daran hindern, bitte dich aber, das etwas fundierter zu tun. Ich beispielsweise rate dringend von <div> ab, ebenso wie von Tabellen. Von Frames sowieso.
Ich habe jetzt eine zweite Beispielseite gemacht.
Ein Beispiel mit einem CSS-Layout ohne <div>
(ich frage mich auch, woher der Aberglaube kommt,
fuer CSS seien DIVs und SPANs notwendig;-)
und ein Beispiel mit einer Layout-Tabelle.
http://www.tiptom.ch/homepage/includes2.htmlIch liste nicht alle Fehler und offensichtliche Missverständnisse auf, da ich davon ausgehe, dass der Artikel so ohnehin unbrauchbar ist. Ich rate dringend davon ab, diesen Artikel als Feature-Artikel zu verwenden, tut mir leid.
Mir tut es auch leid, dass Dein Urteil so vernichtend ist.
Es wuerde mich freuen, wenn Du auch die revidierte
Fassung noch einmal kommentieren koenntest.Gruesse,
Thomas
-
Hallo!
Viele der sprachlichen und inhaltlichen Punkte,
die Du kritisierst, habe ich inzwischen geaendert.
Es wuerde mich freuen, wenn Du auch die revidierte
Fassung noch einmal kommentieren koenntest.Die Einleitung ist, soweit ich es bëurteilen kann, nicht verändert worden und die von mir beanstandeten Teile ebenfalls nicht. Ich wüsste nicht, was es hier neu zu bewerten gäbe.
emu
-
Hallo,
Die Einleitung ist, soweit ich es bëurteilen kann, nicht verändert worden und die von mir beanstandeten Teile ebenfalls nicht. Ich wüsste nicht, was es hier neu zu bewerten gäbe.
Ich befuerchte, dass Du die falsche Seite angeguckt hast.
http://www.tiptom.ch/homepage/includes0.html
ist die unveraenderte Original-Seite, die ich nur
im PS erwaehnt hatte. Dagegen ist
http://www.tiptom.ch/homepage/includes.html
die aktuelle Seite.Ich habe Dein erstes Posting nochmals durchgelesen und
bin der Meinung, dass ich auf die meisten Deiner
Einwaende in der einen oder andern Form reagiert habe.Wenn Du Wert darauf legst, kann ich gerne auch
Punkt fuer Punkt darauf antworten.Gruesse,
Thomas
--
Dank /my/ automatisch ausgeblendet: JavaScript, ASP.
Manuell "ausgeblendet": Threads mit Frames, Iframes und Scrollbalken im Subject...
Bitte keine Mails mit Fachfragen - dafuer gibt es das Forum!-
Hallo Thomas,
Kleiner, logischer Fehler:
| Macromedia rät ausdrücklich davon ab, Vorlagen und Templates zu mischen
Du meinst sicherlich »Libraries und Templates«, oder?
Viele Grüße,
Christian -
Hallo!
[...]
Auf welchen meiner Kritikpunkte bist du denn nun eingegangen? Das erschließt sich mir nämlich beim Vergleich ohne Diff-Tool nicht so ganz.
emu
-
-
Hallo.
bëurteilen
Schöne Schreibweise :-)
MfG, at
-
-
-
Hallo emu,
Weil Du es in [pref:t=67153&m=386251] gewuenscht hast,
beschreibe ich hier, was ich in der aktuellen Version
des Artikels
http://www.tiptom.ch/homepage/includes.html
gegenueber der ersten Version
http://www.tiptom.ch/homepage/includes0.html
u.a. aufgrund Deiner Kritik geaendert habe."Includes" sind HTML-Bausteine, die an einer einzigen Stelle gespeichert sind, aber an mehreren Orten verwendet werden.
Das ist durchaus nicht notwendig.Es ist mir voellig klar, dass man auch eine "leer Huelle"
machen kann, in die man dann mit SSI oder dergleichen
eine vollstaendige HTML-Datei einbindet, so wie Du es tust.Die "normale", gaengige Anwendung von Includes, die ich
beschreiben moechte, ist aber eben gerade, dass man
HTML-_Bausteine_ einbindet und _nicht_ vollstaendige
HTML-Dateien.Und ueblich ist auch, dass man ein Include mehrmals
verwendet, sonst ist es IMHO normalerweise sinnlos,
Includes zu verwenden.
(Abgesehen eben von Sonderfaellen wie bei Dir,
wo je nach Bedingung der eine oder ander Baustein
eingebaut wird.)Ich habe den Satz geaendert.
Neu heisst es:
| "Includes" sind HTML-Bausteine, die an
| einer einzigen Stelle gespeichert sind,
| aber an mehreren Orten verwendet werden können.
^^^^^^Das Aktualisieren geschieht auf Webserver oder bereits auf dem Rechner des Autors.
Welches Aktualisieren? Das ist eine sehr schwammig Formulierung, über die sogar ich, der zumindest nicht Anfänger ist, lange nachdenken musste.Diesen Satz habe ich ersatzlos gestrichen.
Stattdessen habe ich den Text unter
"Beispiel - Fusszeile"
um folgende Abschnitte ergaenzt:| Durch den Include-Mechanismus wird später an der
| Stelle des Platzhalters/Befehls der HTML-Baustein
| aus der entsprechenden Datei (fusszeile.inc) eingefügt.| Dieser Prozess kann entweder noch auf dem Rechner
| des Autors geschehen (siehe Abschnitt "Lösungen mit
| HTML-Editoren") oder aber auf dem Webserver
| (siehe Abschnitt "serverseitige Lösungen").Auch, wenn es meiner und vermutlich deiner Meinung nach unverantwortlich ist, Javascript-»Includes« zu verwenden, diese Möglichkeit zu leugnen, ist nicht sehr schlau.
Ich habe einen entsprechenden Hinweis im letzten Teil
"Missverstaendnisse und Anfaenger-Fragen" gemacht
unter| Funktionieren Includes mit Browser XY?
| [...]
| (Browserabhängige - und somit schlechte und
| sehr unzuverlässige - "Alternativen" zu Includes
| wären das HTML-Element <iframe> sowie einige
| JavaScript-Konstrukte.)Wichtig: Includes dürfen nicht vollständige HTML-Seiten sein, sondern nur Bausteine. Es wäre völlig falsch, eine vollständige HTML-Datei als Include in eine andere einzubetten. Denn somit hätte man im endgültigen Quelltext die Elemente [...] doppelt.
Verquere Logik, siehe mein Gegenbeispiel.Siehe oben, Dein "Gegenbeispiel" ist eben gerade
nicht ein klassisches Beispiel fuer Includes.
Du hast nur eine "leere Huelle" und bindest dort
zufallsgesteuert eine vollstaendige HTML-Datei ein.
Wenn jemand so weit ist, dass er sowas realisieren
will und kann, braucht er hoffentlich meinen
Artikel nicht mehr. Oder dann ist er hoffentlich
genug intelligent, um darauf zu kommen, dass,
wenn er eine vollstaendige Datei einbetten will,
die Huelle "leer" sein muss, also nur gerade
den Include-Befehl, aber nicht auch noch
<html>, <head> und <body> enthalten darf.Ich habe den mittleren Satz geaendert, um Deiner
(selbstgenannten) Pedanterie gerecht zu werden:Es wäre völlig falsch, eine vollständige HTML-Datei
als Include in eine andere vollständige Datei einzubetten.[DHTML]
Kombination von HTML, CSS und JavaScript, also von Dingen, die den Browser/Client betreffen.)
Ich will nicht darauf hinweisen, dass Javascript theoretisch auch auf dem Server laufen kann,Jetzt uebertreibst Du es aber IMHO mit Genauigkeit
und Vollstaendigkeit.Da versuchen wir den Newbies Tag fuer Tag klar zu machen,
dass JavaScript auf dem Client laeuft und deshalb "boese"
und unzuverlaessig ist.Und nun kommst Du mit so theoretischen Moeglichkeiten
wie serverseitigem JavaScript.
Das werde ich im Artikel nicht erwaehnen; es wuerde
IMHO nur Verwirrung stiften und hilft niemandem etwas.aber deine Definition von DHTML ist schlicht falsch, siehe auch andere Wortmeldungen dazu.
Ich habe den Absatz geaendert. Jetzt lautet er so:
| [Dynamische Webseiten] [...]
| (Etwas völlig anderes ist der Begriff Dynamisches
| HTML - "DHTML". Darunter versteht man die Kombination
| von HTML, JavaScript und oft auch CSS. "Dynamisch"
| bedeutet hier: Mit JavaScript werden *im Browser*
| gewisse Inhalte der Seite verändert oder ausgetauscht,
| nachdem der Webserver die Seite an den Browser
| ausgeliefert hat. Diese Effekte setzen aber voraus,
| dass der Browser den JavaScript-Code versteht und ausführt.)Kannst Du mir eine bessere Definition in ein paar Saetzen liefern?
Bei kommerziellem Webspace sollte es meiner Meinung nach selbstverständlich sein, dass SSI, PHP oder andere serverseitige Programmiersprachen zur Verfügung stehen, [...]
Deine persönliche Meinung ist, pardon, irrelevant für diesen Artikel.OK, Du hast recht.
Ich habe diesen Satz gestrichen.
Stattdessen habe ich geschrieben:| In der Leistungsbeschreibung Ihres Webspace-Providers (Webhosts)
| sehen Sie, ob Ihnen SSI, PHP oder andere serverseitige
| Technologien/Programmiersprachen zur Verfügung stehen.Seien wir ehrlich - einer der meistgenannten Gründe, warum so viele Seitenbastler überhaupt Frames verwenden, ist Bequemlichkeit.
[...] Deine Polemik (»Seien wir ehrlich« - an wen richtest du dich denn eigentlich, an den Anfänger oder an Experten?) hat in einem Feature-Artikel nichts zu suchen, höchstens kannst du versuchen, sachlich auf die Probleme hinzuweisen.Der "seien wir ehrlich" Satz war schlecht, ich habe ihn gestrichen.
Anstatt die Nachteile von Frames zu wiederholen, habe ich den Link
zum Artikel von Michael Nahrath (subotnik) an den Anfang des
Abschnitts "Includes als Frames-Ersatz" gestellt.Egal, ob die Navigation in einem <DIV>-Element, in einer Tabellenzelle oder einfach in einer Fusszeile plaziert ist - in allen Fällen reicht ein Include-Befehl/-Platzhalter [...]
Auch noch auf diese Diskussion willst du dich in deinem Artikel einlassen. Ich werde dich nicht daran hindern, bitte dich aber, das etwas fundierter zu tun.
Ich beispielsweise rate dringend von <div> ab, ebenso wie von Tabellen. Von Frames sowieso.In meinem Artikel geht es um Includes.
In dem Abschnitt geht es darum, dass man
auf Frames verzichten kann.Wo die Leute dann in ihrem neuen Layout die
Navigation hinpacken, ist mir persoenlich egal.Wenn Du es schaffst, Deine Seiten ohne Layouttabellen
und ohne ein einziges DIV zu gestalten, dann ziehe
ich vor Dir den Hut.Hast Du mal ein paar Beispiele, fuer optisch ansprechende
Seiten, die auch eine etwas komplexere Navigation
enthalten als nur gerade 5 Links, und die ohne DIV und
Layouttabelle auskommen? (Die Seiten muessen natuerlich
nicht von Dir sein - wenn ja, umso besser! ;-)In meinen Augen ist es schonmal ein Fortschritt,
wenn jemand auf Frames verzichtet und halt noch
_eine_ Layout-Tabelle einsetzt, um links die
Navigation und rechts den Inhalt zu haben.
Es ist nunmal nicht jedermanns Sache, sich
stundenlang mit CSS und der lausigen Browser-
Umsetzung davon mit intensiven Tests auseinander-
zusetzen.Ich will ganz sicher nicht in diesem
Artikel auch noch die Diskussion
Layout-Tabelle vs. DIV-Layout vs. "weder noch",
(was Dir offenbar als beste Loesung vorschwebt)
wiederkaeuen.Ich will nur zeigen, dass alle diese Loesungen
mit Includes moeglich sind.Ich habe folgende neue Saetze in dem Abschnitt:
| In den einzelnen HTML-Seiten steht an der Stelle,
| wo später die Navigation sein soll, der
| Platzhalter/Befehl, um den Baustein einzubinden.
| Dabei spielt es keine Rolle, ob die Navigation
| "einfach so" als HTML-Block im normalen Fluss
| des Dokuments vorkommt (wie z.B. die Fusszeile
| im obigen Beispiel), oder ob sie in einem <DIV>-Element
| oder in einer Zelle einer Layout-Tabelle plaziert ist.Auf der zusaetzlichen Seite mit den zwei
ausfuehrlicheren Beispielen habe ich jetzt
ein Beispiel, wo direkt die UL-Liste mit
der Navigation mit CSS positioniert wird (kein DIV),
und ein anderes Beispiel mit einer Layout-Tabelle:
http://www.tiptom.ch/homepage/includes2.htmlBeim Beispiel mit der Layout-Tabelle
http://www.tiptom.ch/homepage/includes2.html#layouttabelle
weise ich noch kurz darauf hin, dass dieses
nicht der "reinen Lehre" entspricht.
Zudem verlinke ich dort auf das SelfHTML-Kapitel
"Tabellen als Mittel für Web-Seitenlayouts"
http://selfhtml.teamone.de/html/tabellen/layouts.htm
Wenn schon wuerde ich von diesem Kapitel
eine vollstaendige Eroerterung der Problematik
von Layout-Tabellen erwarten.mitkriegen
[...] einfach nur Umgangssprache [...], [...] in einem technischen Artikel nicht adäquat [...]Danke - es war mir nicht bewusst, dass dies ein Helvetismus ist.
Ich habe alle Formulierungen mit "mitkriegen" geaendert.Ich liste nicht alle Fehler und offensichtliche Missverständnisse auf, [...]
Schade, dann bleiben sie naemlich drin... ;-)
Wie Du jetzt hoffentlich siehst, habe ich mir
Deine Kritik zu Herzen genommen, so gut ich konnte,
und ich danke Dir noch einmal fuer Dein ausfuehrliches
Feedback.Wenn Du den Artikel noch immer pauschal "unbrauchbar"
findest, aber mir nicht sagen kannst, woran das liegt,
dann ist mir damit leider nicht sehr geholfen.Ich habe den Artikel jetzt mal den Devs zur Beurteilung
geschickt und warte jetzt auf ihre Antwort.Natuerlich nehme ich gerne auch hier im Forum weiterhin
Kritik, Ergaenzungen und Verbesserungsvorschlaege entgegen,
insbesondere zum Vergleich der serverseitigen Technologien,
der noch immer sehr lueckenhaft ist.Freundliche Gruesse
Thomas
-
-
Hallo Thomas,
- Bei den serverseitigen Programmiersprachen sage ich bis jetzt
kein Wort zu Perl. Erstens kenne ich mich damit zuwenig aus,
zweitens bezweifle ich, dass es geeignet ist fuer blosse Includes
(AFAIK existiert keine Syntax, mit der man Perl-Code mitten
in den HTML-Code einstreuen kann wie z.B. PHP oder SSI),
und drittens befuerchte ich, dass dann staendig Newbies
bei mir (als Autor) oder hier im Forum nachfragen, warum ihre
Perl-Skripten nicht funktionieren, und man ihnen dann ASCII-Upload,
CHMOD und den ganzen Krempel 1000 mal erklaeren muss...
Im Ernst: Falls jemand denkt, dass auch Perl als "Include-Sprache"
geeignet ist und mir den notwendigen Code und/oder Links zu
guten Tutorials schickt, ergaenze ich den Artikel gerne...
Nunja, ich bin kein Perl-Junkie, aber es waere doch wohl auch moeglich, ein Perl-Skript zu schreiben, welches an dem bestimmten Platzhalter einfach beim Aufruf den gewuenschten Code z.B. aus einer Textdatei einbindet, bei einer Aenderung des Codes muss nur das Skript aufgerufen werden. Ein Vorteil ist dabei vielleicht auch, dass man gaanz normale HTML-Dateien verwenden kann, sogar XHTML (wegen der Endung meine ich jetzt, also man bracuht kein .shtml oder .php, sondaern kann die Datei auch mit .xhtml enden lassen).
Was haeltst du davon? Waere das eine Moeglichkeit?
liebe mittagsausgeschlafene Gruesse,
David Schneider - Bei den serverseitigen Programmiersprachen sage ich bis jetzt
-
hi Thomas,
erstmal respekt, dass du dir die mühe gemacht hast, einen solchen artikel zu erstellen!
meine kritikpunkte zum artikel:
1.
Die Kombination von PHP und SSI in einer Datei ist nicht möglich.
sicher?
meines wissen sollte es durchaus möglich sein, den server so zu konfigurieren, dass er eine datei nacheinander durch beide parser schickt. wenn man PHP zur verfügung hat, dürfte dies natürlich in nahezu 100% der fälle unsinnig sein, da SSI m.E. keine features bietet, die man mit PHP nicht ebenso realisieren kann, dem server also die arbeit des doppelten parsens aufzuhalsen, wäre grober unfug.
aber nichts desto trotz spricht AFAIK _theoretisch_ nichts dagegen. also würde ich es vorziehen, dass die behauptung der "unmöglichkeit" durch eine kurze erläuterung zur theoretischen machbarkeit, mit grossem ABER in bezug auf die sinnhaftigkeit in der praktischen umsetzung, ersetzt wird.2.
Wenn reine HTML-Bausteine unverändert eingebettet werden sollen, reicht die Funktion readfile():
<script language="php"> readfile("fusszeile.inc"); </script>diese schreibweise ist m.E. sehr ungewöhnlich - das nachfolgend von dir erwähnte
<?php readfile("fusszeile.inc"); ?>
ist viel gebräuchlicher. und da ich nicht weiss, ob bei der <script>-schreibweise noch irgendwelche fallen und stolpersteine zu beachten sind, würde ich es vorziehen, wenn du <?php ... ?> als erste schreibweise erwähnst, bzw. sogar deutlich als die weitaus gebräuchlichere herausstellst. mir ist jedenfalls niemand bekannt, der die <script>-schreibweise in der praxis benutzt - du etwa?
3.
die funktion virtual(), die du im PHP-teil kurz erwähnst, war mir gar nicht bekannt - also können sogar nicht nur anfänger etwas aus deinem artikel dazulernen :-)
allerdings gehst du im SSI-abschnitt gar nicht auf die dortige virtual-schreibweise des includes ein (hat zwar mit dem virtual() von php wenig gemeinsam, fällt mir nur an dieser stelle auf).
es wird zwar im verlinkten selfhtml-artikel zu SSI erwähnt - aber vielleicht könntest du den unterschied zwischen #include file und #include virtual bei SSI auch noch kurz anschneiden ...?4.
hier wollte ich zunächst auf den hinweis zur sicherheit beim einbinden mit PHP eingehen, da ich mir dachte, hey, bei über http:// angeforderten resourcen bekommst du doch immer nur den bereits geparsten php-code geliefert, also wo soll der unterschied zwischen include oder readfile sein?
bis mir dann einfiel, dass der fremde server ja fieserweise absichtlich den php-code als plain text ungeparsed ausgeben könnte - _guter_ hinweis also, dass wäre sogar mir als eher fortgeschrittenem php-ler nicht auf anhieb als sicherheitsrisiko eingefallen!5.
kleine anmerkung noch zur notation von include und require in PHP:
auch wenn beide befehle im php-manual mit der klammer-schreibweise, also include() und require() in der seitenüberschrift dargestellt werden, sind sie doch keine "richtigen" funktionen.
deshalb ist m.E. die schreibweise
include "dateiname.inc";
require "dateiname.inc";
(wie sie auch das manual in den beispielen gebraucht) der klammer-schreibweise include ("dateiname.inc") bzw. require ("dateiname.inc") vorzuziehen.
aber das ist eher meine persönliche präferenz, falsch ist es in deiner schreibweise natürlich auch nicht.dies sind die paar kleinigkeiten, die mir aufgefallen sind. da ich mit den verschiedenen HMTL-editoren wenig bis gar keine erfahrung habe, halte ich es hier lieber mal mit dieter nuhr ("wenn man keine ahnung hat, einfach mal die ... halten"), und beschränke mich auf obige kritikpunkte bezüglich des serverseitigen includes.
und nochmals, respekt vor der mühe und arbeit, die du dir mit diesem artikel gemacht hast! grosses "danke schön" im namen der SELF-community :-)
gruss,
wahsaga-
Hallo,
erstmal respekt, dass du dir die mühe gemacht hast, einen solchen artikel zu erstellen!
Herzlichen Dank fuer das erste ausdrueckliche Lob in diesem Thread! ;-)
Die Kombination von PHP und SSI in einer Datei ist nicht möglich.
sicher?Ich wusste es: Zu jeder (Faust)Regel gibt es eine Ausnahme ;-)
OK, ich habe Deinen Einwand beruecksichtigt.<script language="php"> readfile("fusszeile.inc"); </script>
vs.
<?php readfile("fusszeile.inc"); ?>Siehe http://www.tiptom.ch/tests/phpssi/einbinden.php
Die <script>-Schreibweise ist IMHO die "stabilste",
auch wenn die <?php ... ?> Schreibweise haeufiger
in Beispielskripten und Tutorials auftaucht.[...] unterschied zwischen #include file und #include virtual bei SSI
Auch das habe ich ergaenzt.
include "dateiname.inc";
require "dateiname.inc";Stimmt, habe ich geaendert, obwohl es +/- ein optisches Detail ist.
und nochmals, respekt vor der mühe und arbeit, die du dir mit diesem artikel gemacht hast! grosses "danke schön" im namen der SELF-community :-)
Bitteschoen!
Ich hoffe, dass ich den Artikel bald einmal in meinen Augen "fertig"
habe, dann werde ich ihn den Devs zur Beurteilung schicken.Gruesse,
Thomas
-
-
Gedankenstriche werde ich nicht als &emdash; oder was es sonst noch gibt codieren. Die "falschen Freunde" sind das stabilste, was es gibt, und ich werde mich nicht ueberzeugen lassen, irgendwelchen Entities zu nehmen, die in alten Browsern "ausgschrieben" dargestellt werden...
Das entspricht auch der Selfaktuell-Regelung.
Ich moechte auch gleich im Inhaltsverzeichnis am Anfang der Seite Sprunglinks auf H3-Ueberschriften machen, und hoffe, dass das OK ist.
Ja. Eine zweite Ebene im Inhaltsverzeichnis wird momentan provisorisch durch Einrückung über mehrere gelöst, da gibt es keine Konvention.
Fuer groessere Bloecke mit Quellcode ist folgendes vorgeschrieben: [...]
Ich finde diesen Quellcode graesslich:
- Voellig ueberfluessige Tabelle
Das ist Unsinn, und das weißt du. Wenn sie überflüssig wäre, könnte sie entfernt bzw. ersetzt werden und der Code würde weiterhin in allen Fällen dieselben Resultate erzielen wie vorher. Und das ist natürlich nicht der Fall.
- presentational Markup (width, cellpadding, bgcolor)
Ich unterstelle dir ebenso, den Sinn und Zweck dahinter zu erkennen, so gräßlich du den Code auch finden magst, er ist historisch gewachsen und funktioniert nach wie vor in dem von ihm erwarteten Sinne.
-
Hallo.
Eine Sprach- und Rechtschreibprüfung nehme ich gern vor, wenn das Dokument tatsächlich seine finale Fassung erreicht hat, also alle Inhalte vorhanden und unmissverständlich sind.
Zu den anderen Aspekten kann ich mich nicht recht äußern, außer zu folgendem:Ich verwende gerne ein separates Stylesheet fuer Print.
Im Screen-Stylesheet blende ich die URLs von Links aus,
im Print-Stylesheet (und ohne CSS) lasse ich sie anzeigen.screen.css:
.printonly { display:none; }HTML:
<a href="http://selfhtml.teamone.de/cgiperl/intro/ssi.htm">SelfHTML-Artikel zu SSI<span class="printonly"> - http://selfhtml.teamone.de/cgiperl/intro/ssi.htm</span></a>Koennte (d.h. "duerfte") ich diese Methode auch in einem
Feature-Artikel verwenden? Also eigenes CSS einsetzen,
um die URLs auf dem Bildschirm auszublenden?Ich halte deine Methode für unglücklich, da die URL-Angabe so zum HTML-Code gehört und daher von entsprechenden Browsern mit vorgelesen werden dürfte. Eine Ergänzung eines jeden einzelnen Links um eine ID sowie je eine ":after"-Zuweisung für diese ID im Print-CSS fände ich sinnvoller.
MfG, at-
hi,
<a href="http://selfhtml.teamone.de/cgiperl/intro/ssi.htm">SelfHTML-Artikel zu SSI<span class="printonly"> - http://selfhtml.teamone.de/cgiperl/intro/ssi.htm</span></a>
Ich halte deine Methode für unglücklich, da die URL-Angabe so zum HTML-Code gehört und daher von entsprechenden Browsern mit vorgelesen werden dürfte.
dann könnte man noch um ein style-sheet für media=aural ergänzen, um dem entgegenzuwirken.
Eine Ergänzung eines jeden einzelnen Links um eine ID sowie je eine ":after"-Zuweisung für diese ID im Print-CSS fände ich sinnvoller.
wie sinnvoll ist eine methode, die im meistverwendeten browser nicht funktionieren wird? (ich gehe davon aus, dass der IE :after nicht plötzloich verstehen wird, nur weil es sich um ein stylesheet für den druck handelt ...?)
gruss,
wahsaga-
Hallo.
dann könnte man noch um ein style-sheet für media=aural ergänzen, um dem entgegenzuwirken.
Das ist sicher richtig, aber der Code bliebe verunziert.
wie sinnvoll ist eine methode, die im meistverwendeten browser nicht funktionieren wird? (ich gehe davon aus, dass der IE :after nicht plötzloich verstehen wird, nur weil es sich um ein stylesheet für den druck handelt ...?)
Deine Einschätzung zum IE teile ich. Nur mache ich mir weniger Gedanken um die Fähigkeiten einzelner Browser als um die Struktur der Dokumente. Aber im konkreten Fall ist dies sicher nicht so wichtig, da die URL ja wenigstens nicht semantisch inkorrekt ist. -- Insofern gebe ich dir für dieses Dokument Recht und wende diese Methode weiter bei meinen Projekten an.
MfG, at-
Nur mache ich mir weniger Gedanken um die Fähigkeiten einzelner Browser als um die Struktur der Dokumente.
at,
Sind deine Seiten nicht für die Nutzer gemacht? Was meinst du interessiert diese mehr, die Darstellung in ihrem Browser oder der Quelltext?
Gunnar--
Good results come from experience; and experience comes from bad results.-
Hallo.
Sind deine Seiten nicht für die Nutzer gemacht? Was meinst du interessiert diese mehr, die Darstellung in ihrem Browser oder der Quelltext?
Ich habe keine Einfluss auf meine Nutzer und kenne deren Browser nicht. Daher schreibe ich Dokumente, die in sich stimmig sind und lebe damit, dass einzelne Kleinigkeiten nicht in jedem Browser vollständig funktionieren.
MfG, at
-
-
-
Hallo,
Eine Ergänzung eines jeden einzelnen Links um eine ID sowie je eine ":after"-Zuweisung für diese ID im Print-CSS fände ich sinnvoller.
Ich auch. Viel sinnvoller und auch oekonomischer.
Noch einfacher ginge es mit reinem CSS, sogar ohne ID.
http://aktuell.de.selfhtml.org/tippstricks/css/drucklayout/index.htm#verweisziel
und aehnliche tolle Ideen sind mir durchaus bekannt.Aber wie wahsaga wahrerweise sagt:
wie sinnvoll ist eine methode, die im meistverwendeten browser nicht funktionieren wird? (ich gehe davon aus, dass der IE :after nicht plötzloich verstehen wird, nur weil es sich um ein stylesheet für den druck handelt ...?)
C'est la vie...
http://aktuell.de.selfhtml.org/tippstricks/css/drucklayout/index.htm#browserchartIch lege relativ viel Wert darauf, dass ein Artikel auch ausgedruckt
moeglichst vollstaendige Informationen enthaelt.
Und eine Linkliste ohne URLs ist IMHO nicht viel wert...Die Idee mit dem "Hartcodieren" der URL in HTML und
dem "Ausblenden" via Aural-Stylesheet gefaellt mir besser.Das geht ja ganz einfach:
<li><a href="http://example.com">Example <span class="printonly"> - http://example.com</span></a></li>
@media screen, projection, handheld, tv, tty, braille, aural
{
printonly { display:none; }
}bzw. einbinden eines externen Stylesheets mit
obigen Medientypen als Attribut im <link>-Tag u.s.w.Ich schaetze mal, dass die Zahl der sehenden Benutzer,
die meinen Artikel mit dem MS IE ausdrucken werden,
groesser sein wird als die Zahl der blinden Benutzer,
die den Artikel von einem Browser vorlesen lassen,
der die obige Syntax nicht versteht und ihnen deshalb
auch die URLs vorlesen wird.Wie gesagt, werde ich die Links _mit_ URL am
Ende des Artikels in der Linkliste gruppieren;
bei den Links im Fliesstext werde ich die URLs
entfernen.Gruesse,
Thomas
-
-
Hallo at,
.printonly { display:none; }
<a href="http://selfhtml.teamone.de/cgiperl/intro/ssi.htm">
SelfHTML-Artikel zu SSI<span class="printonly"> -
http://selfhtml.teamone.de/cgiperl/intro/ssi.htm</span></a>Ich halte deine Methode für unglücklich, da die URL-Angabe so zum HTML-Code
gehört und daher von entsprechenden Browsern mit vorgelesen werden dürfte.Das bezweifele ich. Warum? In der Fahner Image Replacement Technik, die in
der amerikanisches CSS-Szene zur Zeit so beliebt, wird ja ähnlich vorgegangen,
nämlich daß im strukturierenden Element ein span die alternative, also die
Textversion beinhaltet. Nun krankt diese Technik daran, daß Screenreader
durchaus das eigentlich für die Bildschirmdarstellung gedachte display:none;
auch auf sich beziehen, d.h. der Alternativtext wird nicht bedacht bzw.
vorgelesen. Ebenso dürfte das hier der Fall sein. Ich habe die FIR-Entwicklung
nicht weiter beobachtet, aber dort gibt es eventuell interessante Workarounds
für dieses Problem.Trotzdem mag ich diese Lösung intuitiv nicht wirklich. Ich finde, beim
Tippen eines Dokumentes sollte man als Minimum einen Browser ohne CSS
annehmen. Und dann erscheint einem diese Doppelung der URL doch als recht
fragwürdig bis stilistisch falsch. Doch leider ist beim derzeitigem Stand
der Technik dieses noch unmöglich, echte, automatisierte Fußnotentechnik
für den Druck ist erst in CSS 3 angedacht.Ich finde für den Druck ist die Fußnote zur Mitteilung der konkreten URL
das praktischste und für den Leser das nichtstörenste Mittel. Mein Vorschlag
wäre deswegen eine klassische hartkodierte Fußnoteauflistung am Ende, die
eventuell auch in der Bildschirmdarstellung auftauchen kann:Im Fließtext:
<p>... wie man auch Stefan Münz' ausgezeichnetem Kapitel über den
<a href="http://selfhtml.teamone.de/intro/hypertext/index.htm" id="link-6" class="fliesstext">Hypertext</a>
<a class="fussnote" href="#fussnote-6"><sup>[6]</sup></a>
lesen kann ...
</p>(Nein, lasst uns jetzt keine Threaddrift zu <sup> anfangen, ja? ;)
Die Fußnotenauflistung am Ende:
<ol id="fussnotenliste">
...
<li id="fussnote-6">
<a href="http://selfhtml.teamone.de/intro/hypertext/index.htm">
http://selfhtml.teamone.de/intro/hypertext/index.htm
</a>
</li>
...
</ol>Es ist auch eine Zurückverlinkung von der aktuellen Fußnote zurück zum
Fließtext (#link-6) denkbar, ich habe sie hier aber wegen der Klarheit
des Quelltexts gekippt.Ich schreibe mal etwas potentielles CSS auf, das mir zu obigem Beispiel
passen würde, wichtig ist mir aber, das diese Struktur auch ohne CSS
funktionsfähig ist.@media screen {
a.fussnote, ol#fussnotenliste {
display:none;
}
}@media print {
a.fliesstext:link, a.fliesstext:visited {
text-decoration:none;
}
}Aber mehr ist sicherlich auch noch möglich. Ja, meine vorgeschlagene
Struktur ist redundant. Aber sie ist funktionstüchtig ohne CSS
vorauszusetzen, etwas, das manchmal doch wertvoller ist, als bestimmte
Ideale.Tim
-
Hallo.
Ich halte deine Methode für unglücklich, da die URL-Angabe so zum HTML-Code
gehört und daher von entsprechenden Browsern mit vorgelesen werden dürfte.Das bezweifele ich. Warum? In der Fahner Image Replacement Technik, die in
der amerikanisches CSS-Szene zur Zeit so beliebt, wird ja ähnlich vorgegangen,
nämlich daß im strukturierenden Element ein span die alternative, also die
Textversion beinhaltet. Nun krankt diese Technik daran, daß Screenreader
durchaus das eigentlich für die Bildschirmdarstellung gedachte display:none;
auch auf sich beziehen, d.h. der Alternativtext wird nicht bedacht bzw.
vorgelesen. Ebenso dürfte das hier der Fall sein. Ich habe die FIR-Entwicklung
nicht weiter beobachtet, aber dort gibt es eventuell interessante Workarounds
für dieses Problem.Die gibt es nach http://www.stopdesign.com/also/articles/replace_text/#notes durchaus. Und einige weit verbreitete Screenreader handeln ja auch korrekt.
Ich finde für den Druck ist die Fußnote zur Mitteilung der konkreten URL
das praktischste und für den Leser das nichtstörenste Mittel. Mein Vorschlag
wäre deswegen eine klassische hartkodierte Fußnoteauflistung am Ende, die
eventuell auch in der Bildschirmdarstellung auftauchen kann:Ja, eine gangbare Lösung, wie ich finde.
<p>... wie man auch Stefan Münz' ausgezeichnetem Kapitel über den
<a href="http://selfhtml.teamone.de/intro/hypertext/index.htm" id="link-6" class="fliesstext">Hypertext</a>
<a class="fussnote" href="#fussnote-6"><sup>[6]</sup></a>
lesen kann ...
</p>(Nein, lasst uns jetzt keine Threaddrift zu <sup> anfangen, ja? ;)
Nein, aber ...
<ol id="fussnotenliste">
...
<li id="fussnote-6">
<a href="http://selfhtml.teamone.de/intro/hypertext/index.htm">
http://selfhtml.teamone.de/intro/hypertext/index.htm
</a>
</li>
...
</ol>... ob <ol> oder <ul> oder gar -- von mir bevorzugt -- <dl> hier angebracht ist, wurde hier ja vor kurzem ausgiebig diskutiert.
Aber mehr ist sicherlich auch noch möglich. Ja, meine vorgeschlagene
Struktur ist redundant. Aber sie ist funktionstüchtig ohne CSS
vorauszusetzen, etwas, das manchmal doch wertvoller ist, als bestimmte
Ideale.Trotz der Redundanz finde ich sie im Prinzip sehr elegant. Ich werde die Idee in ein wenig abgewandelter Form für mich übernehmen. Danke.
MfG, at
-
-