Trennzeichen zwischen die Links

[Rolf Rost]

Hallo liebe Webworker,

nachdem mir einer schrieb (danke Helmut: DDR Impressum), dass 'Leerzeichen' die Links im Menu meiner HP nicht ausreichend trennen würden

Vorher:
Startseite Index Tiergeschichten Witziges Vermischtes Heimatliches Kochen Urlaub Fotografie

Hab ich mir heute den ganzen Tag nen Kopf gemacht, war am Baggersee und hatte keine Ruhe mit dem Thema.... Also, ich dachte immer, dass außer ein paar Kommas oder Punkten Leerzeichen ausreichend sind um Worte voneinander zu trennen. Siehe oben.

Abba nunne habch doch was Anderes:
Startseite «» Index «» Tiergeschichten «» Witziges «» Vermischtes «» Heimatliches «» Kochen «» Urlaub «» Fotografie

Bin aber nicht so glücklich damit. Kurzum: Hat jemand eine Idee, wie (mit welchem Zeichen) ich die Links in meinem Menu besser und vor allem unmissverständlich trennen kann?

Eine Grafik möchte ich vermeiden, aber wenn jemand sowas hat, schau ichs mir gerne an und machs dann auso.

Gruss, Rolf

[Thomas Meinike]

Hallo,

Kurzum: Hat jemand eine Idee, wie (mit welchem Zeichen) ich die Links in meinem Menu besser und vor allem unmissverständlich trennen kann?

Link | Link | Link

MfG, Thomas

[Xava]

Link | Link | Link

Oder: «Link» «Link» «Link»
Oder: »Link »Link »Link
Oder: ->Link ->Link ->Link
usw.

[siro]

Hallo Xava.

Oder: »Link »Link »Link
Oder: ->Link ->Link ->Link

Die würde ich nicht empfehlen, da es nicht wie eine Aufzählung aussieht, sondern wie eine typische "Sie sind hier:"-Linkfolge.

MfG _Siro

[Rolf Rost]

hi,

Oder: ->Link ->Link ->Link

Die würde ich nicht empfehlen, da es nicht wie eine Aufzählung aussieht, sondern wie eine typische "Sie sind hier:"-Linkfolge.

Für eine alternative (LinkX ODER LinkY ODER LinkA) 'Liste' ists wirklich nicht gut. Aber für die Darstellung von Breadcrumbs ist das sehr gut geeignet!

Gruss, Rolf

[Fabian Transchel]

Hi Rolf,

Bin aber nicht so glücklich damit. Kurzum: Hat jemand eine Idee, wie (mit welchem Zeichen) ich die Links in meinem Menu besser und vor allem unmissverständlich trennen kann?

Thomas hat dir die Pipe ja schon vorgeschlagen, die verwende ich auch, wenn stilistisch Leerzeichen nicht schön sind. Was spricht aus deiner Sicht gegen Leerzeichen? Wenn nur der Abstand zu gering ist, dann mach display:block; float:right; und gib den Links 'nen Margin.

Grüße aus Barsinghausen,
Fabian

[Ingo Turski]

Hi,

nachdem mir einer schrieb (danke Helmut: DDR Impressum), dass 'Leerzeichen' die Links im Menu meiner HP nicht ausreichend trennen würden

hat er Dir auch geschrieben, _warum_ das so ist? Nämlich daß Link direkt aneinandergesetzt ohne CSS-Formatierung nicht deutlich voneinander getrennt sind. Wenn Du das berücksichtigst, dann hast Du auch gleich eine Methode gefunden, um Links sauber voneinander zu trennen: verwende eine Liste. Diese ist ohne CSS über die Listenpunkte getrennt.
Und daß Du eine Liste beliebig und meist vielseitiger als andere Elemente formatieren kannst, dürftest Du ja wissen.

freundliche Grüße
Ingo

[Rolf Rost]

Hi Ingo,

Und daß Du eine Liste beliebig und meist vielseitiger als andere Elemente formatieren kannst, dürftest Du ja wissen.

Das ist interessant! Wie krieg ich denn eine Liste ins Horizontale?

Gruss, Rolf

[ichen]

Moin Rolf!
mit display:inline; müsste es gehen.
tschüss ichen

[Fabian Transchel]

Hallo ichen,

mit display:inline; müsste es gehen.

Ja, das beraubt ihn aber der möglichkeit, für alle Links gleiche Längen zu definieren.

Grüße aus Barsinghausen,
Fabian

[Fabian Transchel]

Hallo Rolf

Und daß Du eine Liste beliebig und meist vielseitiger als andere Elemente formatieren kannst, dürftest Du ja wissen.

Warum? Bloß weil ich Bullets vergeben darf? Versteh mich nicht falsch, ich mache Navigationen üblicherwiese auch als Listen, aber dein Argument erschießt sich mir im Zusammenhagn mit _formatieren_ nicht völlig - die semantische Komponente ist mir bewusst.

Das ist interessant! Wie krieg ich denn eine Liste ins Horizontale?

float ist dein Freund.

Grüße aus Barsinghausen,
Fabian

[Beat]

Hallo Rolf

Das ist interessant! Wie krieg ich denn eine Liste ins Horizontale?

float ist dein Freund.

Grüße aus Barsinghausen,
Fabian

und wo bleibt da die Logik:

dies oder das oder jenes (in der horizontale)

dies
dann das
dann jenes

Ein serieller Kontext in der Vertikalen

Rolfs Auswahl besteht aus gleichwertigen Themen die keine serielle Logik haben.

schon aus der PERL Syntax gedacht erscheint

dies | jenes | anderes

assoziativ richtig

mfg Beat

[Rolf Rost]

hi Beat,

schon aus der PERL Syntax gedacht erscheint

dies | jenes | anderes

assoziativ richtig

Das stimmt ;-)

Das ist ne richtige EDVler Mucke:
Vater geworden. Was hast Du, Junge ODER Mädchen?
Antwort: Ja.

Gruss, Rolf

PS: Das Pipedingens sieht wirklich noch am Besten aus.
Es trennt Optisch. Es trennt Logisch. Logisch.

[siro]

Hallo Rolf.

PS: Das Pipedingens sieht wirklich noch am Besten aus.
Es trennt Optisch. Es trennt Logisch. Logisch.

Da gibt's nur eins, was noch schickerer ist:

Pipes DX:

1. Links inne Liste
2. Lis floaten lassen
3. einen Rahmen an die Seite der Lis
4. Fertig

Dann hast du 'Pipes', die du fast unabhänging vom Text formatieren kannst - Pipes DX halt.

MfG _Siro

[Cheatah]

Hi,

Dann hast du 'Pipes', die du fast unabhänging vom Text formatieren kannst - Pipes DX halt.

und wenn man mal etwas anderes als Pipes haben möchte:

li:not(:last-child):after { content: '/'; padding: 0 0.5em; }

Cheatah ;-)

[siro]

Hallo Cheatah.

und wenn man mal etwas anderes als Pipes haben möchte:

li:not(:last-child):after { content: '/'; padding: 0 0.5em; }

Da musst du wohl noch ein paar Jahre warten.
Ich hab es gerade mal getestet und selbst Opera7 hat sich geweigert das ":not(:last-child)" zu verstehen.

MfG _Siro

[Cheatah]

Hi,

li:not(:last-child):after { content: '/'; padding: 0 0.5em; }
Da musst du wohl noch ein paar Jahre warten.

Mozilla kann's seit langem. Das reicht doch ;-)

Cheatah

[Orlando]

Hi Cheatah,

li:not(:last-child):after { content: '/'; padding: 0 0.5em; }
Da musst du wohl noch ein paar Jahre warten.
Mozilla kann's seit langem. Das reicht doch ;-)

Wenn du viel Zeit hast, ja. Manche bevorzugen einen flotten Browser ]:-)

li+li:before { content: '/'; padding: 0 0.5em; }

Das funktioniert auch in Opera und ist auch nicht so umständlich.

Grüße,
 Roland

[siro]

Hallo Roland.

Wenn du viel Zeit hast, ja. Manche bevorzugen einen flotten Browser

Stimmt. Deshalb nehm ich auch den Firefox. :-P

MfG _Siro

[Rolf Rost]

Hallo Roland.

Wenn du viel Zeit hast, ja. Manche bevorzugen einen flotten Browser

Stimmt. Deshalb nehm ich auch den Firefox. :-P

MfG _Siro

[Orlando]

Hi siro,

Wenn du viel Zeit hast, ja. Manche bevorzugen einen flotten Browser

Stimmt. Deshalb nehm ich auch den Firefox. :-P

Heißt der denn noch so? >;) Zum Thema: siehe [pref:t=86115&m=509739] ff.

Grüße,
 Roland

[Sven]

Moin Beat,

Das ist interessant! Wie krieg ich denn eine Liste ins Horizontale?
float ist dein Freund.
und wo bleibt da die Logik:
dies oder das oder jenes (in der horizontale)
dies
dann das
dann jenes
Ein serieller Kontext in der Vertikalen
Rolfs Auswahl besteht aus gleichwertigen Themen die keine serielle Logik haben.

der Kontext bleibt gleich, wenn du eine Auflistung in der horizontalen oder vertikalen machst, finde ich.

also:

a b c d e f

* a
* b
* c
* d
* e
* f

Die Liste ist logischer, weil das ganze ja eine Linkliste ist, auch wenn horizontal. Listen sind dementsprechend besser zu formatieren, bieten eine bessere Übersicht ohne CSS.

schon aus der PERL Syntax gedacht erscheint
dies | jenes | anderes
assoziativ richtig

Was hat Perl damit zu tun!?

Gruß,

Sven

[Beat]

der Kontext bleibt gleich, wenn du eine Auflistung in der horizontalen oder vertikalen machst, finde ich.

also:

a b c d e f

* a
* b
* c
* d
* e
* f

Die Liste ist logischer, weil das ganze ja eine Linkliste ist, auch wenn horizontal. Listen sind dementsprechend besser zu formatieren, bieten eine bessere Übersicht ohne CSS.

ja hallo Sven
Eine Liste ist an und für sich ganz praktisch bei

• gleichwertigen Dingen
• geordneten Dingen

aber überleg mal dies
home
contact
segeln
webdesign
impressum

In eine Liste kann ich es ja stellen. Und zwar aus dem einfachen Grund, weil es eine Liste von LINKS ist.
Aber wegen dem sind diese dinge nicht gleichwertig, und eine andere Lösung wäre hier ebenso gut.

Wäre die Eigenschaft _Link_ genügend dann

• könnte
• ich
• grundsätzlich
• auch
• alle
• worte
• in
• einer
• Liste
• unterbringen.

Schuhschachteln sind gut für Schuhe und andere Dinge, aber nicht unbedingt für eine Briefmarkensammlung oder mein Werkzeug.

schon aus der PERL Syntax gedacht erscheint
dies | jenes | anderes
assoziativ richtig

Was hat Perl damit zu tun!?

Gruß,

Sven

ja das ist eine gute Frage.
Woher kommt die Semantik von diesen Dingern die den Bildschirm verschmutzen?
Perl fand, dass die Pipe geeignet mit einer ODER Verknüpfung assoziert sei.
Irgend eine Vorgeschichte muss das haben, aber die will ich hier jetzt nicht recherchieren.

mfg Beat

[Sven]

ja hallo Sven

ja hallo beat,

Eine Liste ist an und für sich ganz praktisch bei

• gleichwertigen Dingen
• geordneten Dingen

Idr. sind Links in Linklisten gleichwertig. Ansonsten kommen beispielsweise untergeordnete Links in eine untergeordnete Liste (verschachtelte Liste).

aber überleg mal dies
home
contact
segeln
webdesign
impressum

geht wunderbar. Kann ich jetzt toll mit CSS formatieren - besser, als ich es mit <a>'s könnte, die mit Leerzeichen voneinander getrennt wären.

Viele schöne Beispiele bietet beispielsweise http://css.maxdesign.com.au/listamatic/ bzw. http://css.maxdesign.com.au/.

In eine Liste kann ich es ja stellen. Und zwar aus dem einfachen Grund, weil es eine Liste von LINKS ist.

absolut richtig. Und dann ist es auch LOGISCHER wenn man es in eine Liste steckt.

Aber wegen dem sind diese dinge nicht gleichwertig, und eine andere Lösung wäre hier ebenso gut.

wegen dem -was-? Es sind doch alles links.

Wäre die Eigenschaft _Link_ genügend dann

• könnte
• ich
• grundsätzlich
• auch
• alle
• worte
• in
• einer
• Liste
• unterbringen.

Quatsch. Du hast hier einen Fließtext. Das lässt sich nicht in eine Liste bringen.

Schuhschachteln sind gut für Schuhe und andere Dinge, aber nicht unbedingt für eine Briefmarkensammlung oder mein Werkzeug.

der Vergleich hinkt.

schon aus der PERL Syntax gedacht erscheint
dies | jenes | anderes
assoziativ richtig
Was hat Perl damit zu tun!?
Woher kommt die Semantik von diesen Dingern die den Bildschirm verschmutzen?

Du fragst, woher die "|" striche kommen?

Perl fand, dass die Pipe geeignet mit einer ODER Verknüpfung assoziert sei.

hm - versteh ich jetzt nicht. Afaik werden Pipes in Perl mit nach dem Muster "|name" angesprochen / bezeichnet. Der "oder"-operator lautet - wenn überhaupt - "||".

Gruß,

Sven

[Ingo Turski]

Hi,

Hallo Rolf

Und daß Du eine Liste beliebig und meist vielseitiger als andere Elemente formatieren kannst, dürftest Du ja wissen.

Warum? Bloß weil ich Bullets vergeben darf? Versteh mich nicht falsch, ich mache Navigationen üblicherwiese auch als Listen, aber dein Argument erschießt sich mir im Zusammenhagn mit _formatieren_ nicht völlig - die semantische Komponente ist mir bewusst.

da ich das gesagt hatte ;-) will ich's auch begründen:
Wenn ich mein Menü als Liste auszeichne, habe ich drei Elemente, die ich über CSS "formatieren" kann, setze ich die Links z.B. nur in ein <p>, dann habe ich nur noch zwei. Außerdem habe ich noch zusätzlich die Option, das Bullet sichtbar zu machen. Ich werde also vermutlich für jedes späteres Design übr CSS zustande bekommen, ohne in den xHTMl-Quelltext nochmals eingreifen zu müssen.

Das ist interessant! Wie krieg ich denn eine Liste ins Horizontale?

float ist dein Freund.

das kommt drauf an, ob eine feste Weite gewünscht wird oder - wie im vorliegenden Fall - eben nicht. Dafür wäre dann display:inline angebracht, was aber auch schon gesagt wurde.

freundliche Grüße
Ingo

[dbenzhuser]

N'Obend

Nämlich daß Link direkt aneinandergesetzt ohne CSS-Formatierung nicht deutlich voneinander getrennt sind. Wenn Du das berücksichtigst, dann hast Du auch gleich eine Methode gefunden, um Links sauber voneinander zu trennen: verwende eine Liste.

Auch kein Allheilmittel:
http://www.einfach-fuer-alle.de/artikel/menues/tag2/
(Etwas weiter unten, "Links trennen")
Beachtenswert auch die folgende Seite, insb. CSS zum verbergen der Punkte und der kleine Kasten über "|" als Trennzeichen.

Ich hatte den Artikel mal überflogen, mehr nicht.
Müsst euch also leider selbst ein Urteil bilden, ob er wirklich Relevanz hat... (müsstet ihr auch wenn ich ihn besser gelesen hätte, wer weiß schon was ich verzapfe...)

Tschö, ich muss weg,
dbenzhuser

[Ingo Turski]

Hi,

Auch kein Allheilmittel:
http://www.einfach-fuer-alle.de/artikel/menues/tag2/

ein interessanter Aetikel. Aber so sehr icgh EfA auch schätze, ich finde doch, daß sie hier übertreiben.

"Manche assistiven Geräte oder Textbrowser trennen Links in Listeneinträgen nicht zuverlässig."
Keine Angabe, welche das denn sein sollen und wieweit diese tatsächlich verbreitet sind. Außerdem würde dies mMn ein Softwarefehler sein und ich halte die Forderung, jeglichen Softwarefehlern Rechnung zu tragen für unrealistisch. dies würde bedeuten, daß sobald eine neue fehlerhafte Software auf den Markt kommt, alle sich barrierefrei nennenden Seiten hieran angepaßt werden müßten?

"Dabei handelt es sich auch um eine Forderung der WCAG1.0 bzw. der BITV (Punkt 10.5), die hier leider nicht besonders praxisorientiert ist. Dort wird das (Interims-)Trennzeichen als Kann-Richtlinie verhandelt"
Und daran fine ich nichts auszusetzen.

Übrigens finde ich das Menübeispiel in einem Punkt völlig daneben:

"<h1>Navigation:</h1>"

Welchen Sinn macht es, "Navigation" als Überschrift erster Ordnung auszuzeichnen? Ich glaube, hier haben die wirklich nicht nachgedacht.

freundliche Grüße
Ingo

[sven]

Moin Rolf,

ich zitiere, http://home.vr-web.de/rolfrost/impressum.html, :

--------------------------
                        <p>In der Erstellung der Seiten lege ich ein besonderes Gewicht auf <i>valides HTML</i>, so wie es vom w3 - Konsortium empfohlen wird und selbstverständlich auch Wert auf Barrierefreiheit.

<p>
                        <pre>
                Rolf Rost
                Luisenstra&szlig;e 19a

76351 Linkenheim-Hochstetten

Tel.:        [phone]
                eMail:        [e-mail]
                        </pre>

--------------------------

Die Betonung auf Barrierefreiheit. Ich hoffe, du bist dir sicher, was du da schreibst? Deine Adressangaben in <pre>, das ist ganz und gar nicht Barrierefrei.

Barrierefrei wäre <adress> (oder so ähnlich) mit CSS formatiert.

Barrierefrei wäre ein Menü, welches in einer Liste vorliegen würde (<ul>)

Mehr fällt mir gerade nicht ein. Das musste ich jetzt einfach mal loswerden, *scnr*

Gruß,

Sven

[Gunnar Bittersmann]

Barrierefrei wäre <adress> (oder so ähnlich) mit CSS formatiert.

Sven,
So ähnlich: mit Doppel-D.

Sicher ist address das beste Element, um in HTML eine Adresse auszuzeichnen, aber was hat das mit Barrierefreiheit zu tun?
Gunnar

[Sven]

Hallo Gunnar,

Barrierefrei wäre <adress> (oder so ähnlich) mit CSS formatiert.
So ähnlich: mit Doppel-D.

ok, <address>, danke :)

Sicher ist address das beste Element, um in HTML eine Adresse auszuzeichnen, aber was hat das mit Barrierefreiheit zu tun?

Ich bitte dich. Im Absatz steht in etwa "Ich lege Wert auf Barrierefreiheit und valide Seiten" und danach kommt ein <p><pre> - nur einmal unvalide, sowie ein Text, der durch <pre> eingeschoben wurde, und zwar mit leerzeichen! Das ist doch alles andere als das Verhindern von Barrieren!!!

Gruß,

Sven

[Rolf Rost]

Hallo,

Ich bitte dich. Im Absatz steht in etwa "Ich lege Wert auf Barrierefreiheit und valide Seiten" und danach kommt ein <p><pre> - nur einmal unvalide, sowie ein Text, der durch <pre> eingeschoben wurde, und zwar mit leerzeichen! Das ist doch alles andere als das Verhindern von Barrieren!!!

Für mich ist die BITV maßgeblich. Zitiere mir einer die Stelle in der BITV wo geschrieben steht dass der pre-Tag eine Barriere darstellt.

Bitte.

Gruss, Rolf

[Armin G.]

Tach auch,

Für mich ist die BITV maßgeblich. Zitiere mir einer die Stelle in der BITV wo geschrieben steht dass der pre-Tag eine Barriere darstellt.

Du hast Nr 3 gelesen? In Verbindung mit Nr 12, dabei insbesondere 12.3 und 12.4?

Da steht zwar nicht dass pre eine Barriere darstellt, aber dort wird gefordert dass semantisch korrekt ausgezeichnet wird. Und da sollte jawohl <address> fuer die Adresse die zu erwartende Methode sein.

Gruss,
Armin

[Rolf Rost]

Dopryi djen tawarischtsch,

Du hast Nr 3 gelesen? In Verbindung mit Nr 12, dabei insbesondere 12.3 und 12.4?

Da steht zwar nicht dass pre eine Barriere darstellt, aber dort wird gefordert dass semantisch korrekt ausgezeichnet wird. Und da sollte jawohl <address> fuer die Adresse die zu erwartende Methode sein.

Nicht einmal das Wort semantisch hab ich in BITV gefunden. Zeigts mir... bitte.

Gruss, Rolf

[Armin G.]

Tach auch,

Du hast Nr 3 gelesen? In Verbindung mit Nr 12, dabei insbesondere 12.3 und 12.4?

Nicht einmal das Wort semantisch hab ich in BITV gefunden. Zeigts mir... bitte.

Natuerlich steht das da nicht. Aber muss es dort wortwoertlich stehen wenn es dort sinngemaess steht?

Gruss,
Armin

[Rolf Rost]

Jo Armin,

Natuerlich steht das da nicht. Aber muss es dort wortwoertlich stehen wenn es dort sinngemaess steht?

Selbstverständlich! Das BITV ist schließlich eine Gesetzgebung und hier in Deutschland ist es so, dass Gesetze nicht jeder so auslegen darf wie er lustig ist (oder vielleicht doch nicht eventuell) !?

Bis auf die die vor dem Gesetzgeber gleicher sind als die Anderen ;-)

Gruss, Rolf

[Gunnar Bittersmann]

Da steht zwar nicht dass pre eine Barriere darstellt, aber dort wird gefordert dass semantisch korrekt ausgezeichnet wird. Und da sollte jawohl <address> fuer die Adresse die zu erwartende Methode sein.

Armin,
HTML hat nichts mit semantischer Auszeichnung zu tun.
Gunnar

[Daniel Thoma]

Hallo Gunnar,

HTML hat nichts mit semantischer Auszeichnung zu tun.

Könntest Du etwas näher erleutern, wie Du zu dieser Behauptung kommst?

Grüße

Daniel

[Mathias Bigge]

Hi Daniel,

HTML hat nichts mit semantischer Auszeichnung zu tun.
Könntest Du etwas näher erleutern, wie Du zu dieser Behauptung kommst?

Ich kann nur für mich sprechen, aber dieses ganze Semantik vs. Form-Gerede hier im Forum ist oft wirklich extrem undurchdacht.

Häufig wird die Forderung, gleichen inhaltlichen Elementen die gleichen Formate zuzuordnen als Trennung von Form und Inhalt bezeichnet. Korrekt wäre das nur, wenn das HTML einfach keinerlei Formatierungen enthielte.

Das viel zitierte semantische Markup wird oft auch überstrapaziert: Tatsächlich stehen nur wenige Tags zur Verfügung, die über technische Beschreibungen hinaus geeignet sind, inhaltlich zu differenzieren. Eine wirklich sinnvolle inhaltliche Strukturierung von beliebigen Dokumenten erfordert m.E. selbstdefinierte Tags, wenn der Aussagewert der Bezeichner nicht gegen Null gehen soll. Deshalb wird hier auch immer wieder auf den drei armen Tags h, table und p herumgeritten. Ich behaupte, dass der Informationsgewinn der Auszeichnungen div und span gegenüber table gegen Null geht.

Das Gesamtkunstwerk eignet sich allerdings hervorragend zur Prinzipienreiterei, und einige machen sich hier zu Automaten der Hinweiswiederholung, wenn ein armer Wicht es wagt drei Bilder mit einer Tabelle auszurichten anstatt mit herrlich informativen DIVs.

Ich nehme Dein Posting nur zum Anlass, nicht dass jemand meint, ich wolle Dir etwas unterstellen, aber diese Semantik-Postings, ihr wisst schon, welche ich meine, tragen deutlich zur Inhaltsleere und Langeweile im Forum bei...

Viele Grüße
Mathias Bigge

[Daniel Thoma]

Hallo Mathias,

Ja sicher, mit HTML kann man ein Dokument nicht in dem Sinne semantisch auszeichnen, dass man dadurch wirklich den Inhalt beschreibt.
Von daher kann man sich auch darüber streiten, ob man solche Elemente wie address oder gar code überhaupt benötigt, da diese Elemente eigentlich keine Strukturelemente, wie sie in jedem Dokument vorkommen (Tabellen Absätze Überschrifften Listen) sind, sondern einem Textabschnitt schon eine gewisse Bedeutung zuordnen, wofür HTML tatsächlich nicht geeignet ist.
So gesehen hat HTML wirklich nicht (direkt) mit der Semantik des ausgezeichneten Textes zu tun, aber es beschreibt eben die Struktur eines Dokuments und enthält so mehr Information, als die reine Formatierung des Dokuments.
Nun sollte man deshalb die Trennung von Struktur und Formatierung nicht zum Dogma erheben, aber nützlich ist sie idR. schon-
Schließlich macht sie den Quelltext übersichtlicher und das Dokument unter (fast) allen Bedingungen darstellbar. Gerade die von dir angesprochene Tabelle ist da viel eher ein Problem, als die nichtauszeichnung von Adressen mit address ;-)

Eigentlich hatte ich ja nicht vor, eine Begründung, warum Gunnar in gewisser Weise recht hat, gleich mit zu liefern...

Grüße

Daniel

[Gunnar Bittersmann]

Eigentlich hatte ich ja nicht vor, eine Begründung, warum Gunnar in gewisser Weise recht hat, gleich mit zu liefern...

Daniel,
Danke trotzdem. ;-)

Da das doch recht weit vom Thread driftet: [pref:t=86366&m=510790]
Gunnar

[Fabian Transchel]

Hallo Gunnar,

HTML hat nichts mit semantischer Auszeichnung zu tun.

Womit willst du das untermauern?

Grüße aus Barsinghausen,
Fabian

[Sven]

Moin Rolf,

Ich bitte dich. Im Absatz steht in etwa "Ich lege Wert auf Barrierefreiheit und valide Seiten" und danach kommt ein <p><pre> - nur einmal unvalide, sowie ein Text, der durch <pre> eingeschoben wurde, und zwar mit leerzeichen! Das ist doch alles andere als das Verhindern von Barrieren!!!
Für mich ist die BITV maßgeblich. Zitiere mir einer die Stelle in der BITV wo geschrieben steht dass der pre-Tag eine Barriere darstellt.

Ich kenne kein BITV; wenn das für dich maßgeblich ist, würde ich es auf dein Impressum dazuschreiben.

Ansonsten denke ich kann man das <pre>-Tag sicher anweden, eine Barriere stellen beispielsweise breite Texte (>70 Zeichen in der Spalte) für kleine Monitore oder sogar PDA's und so ein Zeugs sicherlich dar.

Und wenn man <pre>'s gut verhindern kann bzw. es unsinnig ist, sie einzusetzten (<pre>'s sind für dafür da, dass der text so dargestellt wird, wie eingegeben. du nutzt sie auf deiuner impressumsseite für's design. Dafür ist aber CSS da, mit dem sich die "Festbreitenschrift" vom <pre> ohne weiteres einstellen lässt).

Gruß,

Sven

[Gunnar Bittersmann]

ein Text, der durch <pre> eingeschoben wurde, und zwar mit leerzeichen! Das ist doch alles andere als das Verhindern von Barrieren!!!

Sven,
Ich wüsste ehrlich gesagt nicht, was präformatierter Text für Barrieren aufbauen sollte. (Wenn er nicht so lang ist, das man horizontal scrollen muss. Obwohl ich das allgemeiner unter Usability laufen lassen würde.)
Gunnar

[MudGuard]

Hi,

danach kommt ein <p><pre> - nur einmal unvalide,

Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
In transitional ist das schließende Tag von p optional - der Absatz geht also höchstens bis zum ersten Element, das nicht in p vorkommen darf. Also bis vor das <pre>

cu,
Andreas

[Sven]

Moin MudGuard,

danach kommt ein <p><pre> - nur einmal unvalide,
Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?

ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.

In transitional ist das schließende Tag von p optional - der Absatz geht also höchstens bis zum ersten Element, das nicht in p vorkommen darf. Also bis vor das <pre>

HTML ist auch schon eine verrückte Sache. Da sind zahlreiche Schließtags optional ;-) - irgendwie bin ich so "strikt" in letzter Zeit, da ich fast nur noch mit XML und XHTML arbeite :/

Gruß,

Sven

[MudGuard]

Hi,

danach kommt ein <p><pre> - nur einmal unvalide,
Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.

Nein.

cu,
Andreas

[MudGuard]

Hi,

danach kommt ein <p><pre> - nur einmal unvalide,
Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.

Versehentlich zu früh abgeschickt.
Es sollte heißen:

Ja - Nein.

cu,
Andreas

[Sven]

Moin MudGuard,

danach kommt ein <p><pre> - nur einmal unvalide,
Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.
Versehentlich zu früh abgeschickt.
Es sollte heißen:
Ja - Nein.

kommt noch was danach?

Gru*scnr*ß,

sven

[MudGuard]

Hi,

Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.
Versehentlich zu früh abgeschickt.
Es sollte heißen:
Ja - Nein.
kommt noch was danach?

Ne, wieso auch. Ist doch alles gesagt.

cu,
Andreas

[Sven]

Moin Mudguard,

Inwiefern ist ein leerer Absatz vor einem pre-Element in HTML 4.01 transitional unvalide?
ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.
Versehentlich zu früh abgeschickt.
Es sollte heißen:
Ja - Nein.
kommt noch was danach?
Ne, wieso auch. Ist doch alles gesagt.

nö. Mir fehlt eine Begründung für das "Jein" :)

Gruß,

sven

[MudGuard]

Hi,

ja, ich habe mich mal wieder geirrt ;-) - in strict ist es unvalide.
Ja - Nein.

kommt noch was danach?
Ne, wieso auch. Ist doch alles gesagt.
nö. Mir fehlt eine Begründung für das "Jein" :)

Das Ja vor dem - bezieht sich auf den Teil Deines Satzes vor dem -.
Das Nein nach dem - bezieht sich auf den Teil Deines Satzes nach dem -.

cu,
Andreas

[Christian Kruse]

Hallo Sven,

danach kommt ein <p><pre> - nur einmal unvalide,
Inwiefern ist ein leerer Absatz vor einem pre-Element in
HTML 4.01 transitional unvalide?

ja, ich habe mich mal wieder geirrt ;-) - in strict ist es
unvalide.

Ja, du hast dich geirrt. Es ist valide. HTML ist eine SGML-Anwendung,
folgendes ist ein valides HTML-Dokument:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>valides</title>

<p>HTML

Jags durch den Validator, der wird dir lediglich anmeckern, dass
er den Zeichensatz nicht erkennen konnte.

Grüße,
 CK

[Rolf Rost]

Guten Morgen Sven,

Barrierefrei wäre ein Menü, welches in einer Liste vorliegen würde (<ul>)

Wir lesen nach, das steht im BITV zu Listen:

cite
Zur Darstellung von Listen und Listenelementen sind die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache zu verwenden.
/cite

Psst, auf
http://home.vr-web.de/rolfrost/mountainbike.html
habe ich tatsächliche eine PseudoListe wo das noch nicht umgesetzt ist, mach ich aber demnächst. Das hat jedoch primär mit einem Menu nichts zu tun.

Mehr fällt mir gerade nicht ein. Das musste ich jetzt einfach mal loswerden, *scnr*

Aber mir fällt noch was ein: Meine Seiten sind valide. Ich bin jedoch der Meinung, dass ich das NICHT auf jede Seite schreiben muss (HTML valid, CSS valid - da gibts Bilderchen die manche auch haben), weil es den Besucher möglicherweise nicht unbedingt interessiert.

z.B.
http://validator.w3.org/check?uri=http%3A%2F%2Fhome.vr-web.de%2Frolfrost%2F
und die anderen Dateichen auch ;-)

Gruss, Rolf

[Sven]

Hallo Rolf,

Barrierefrei wäre ein Menü, welches in einer Liste vorliegen würde (<ul>)
Wir lesen nach, das steht im BITV zu Listen:

BITV?

Zur Darstellung von Listen und Listenelementen sind die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache zu verwenden.

ja. und?

Psst, auf
http://home.vr-web.de/rolfrost/mountainbike.html
habe ich tatsächliche eine PseudoListe wo das noch nicht umgesetzt ist, mach ich aber demnächst. Das hat jedoch primär mit einem Menu nichts zu tun.

darum geht bzw. ging es mir jetzt auch nicht.

Mehr fällt mir gerade nicht ein. Das musste ich jetzt einfach mal loswerden, *scnr*
Aber mir fällt noch was ein: Meine Seiten sind valide. Ich bin jedoch der Meinung, dass ich das NICHT auf jede Seite schreiben muss (HTML valid, CSS valid - da gibts Bilderchen die manche auch haben), weil es den Besucher möglicherweise nicht unbedingt interessiert.
z.B.
http://validator.w3.org/check?uri=http%3A%2F%2Fhome.vr-web.de%2Frolfrost%2F
und die anderen Dateichen auch ;-)

Hm, stimmt tatsächlich, <p><pre> ist scheinbar nur in Strict unvalide, und du verwendest ja Transitional.

Gruß,

Sven

[Rolf Rost]

Hallo liebe Forumer,

es geht mir seit Tagen durch den Kopf und hier steht ja auch alles (mit 'bitv' in google ratz fatz gefunden):

http://www.wob11.de/gesetze/bitv.html

Aber offensichtlich gibt es immer wieder Unklarheiten über diese Gesetzgebung und vor allem gibt es Unklarheiten über die Umsetzung - so lese ich das hier aus dem Forum...

Also liebe Webkollegen, lest das mal durch und wer Lust hat, darüber einen Featureartikel für den SELFRaum zu schreiben möge es tun, Bitte.

Gruss, Rolf

[Rolf Rost]

Hallo liebe Forumer,

es geht mir seit Tagen durch den Kopf und hier steht ja auch alles (mit 'bitv' in google ratz fatz gefunden):

http://www.wob11.de/gesetze/bitv.html

Aber offensichtlich gibt es immer wieder Unklarheiten über diese Gesetzgebung und vor allem gibt es Unklarheiten über die Umsetzung - so lese ich das hier aus dem Forum...

Also liebe Webkollegen, lest das mal durch und wer Lust hat, darüber einen Featureartikel für den SELFRaum zu schreiben möge es tun, Bitte.

Jow, das Thema beschäftigt mich halt ....

Hab noch was gefunden:

http://www.benutzerfreun.de/newsletter/2003_01_Barrierefreie_Sites.html

was als Grundlage für einen Feature Artikel für den SELF raum dienen könnte.

Viele Grüße, Rolf