SELFHTML Forum
SELFHTML Forumsarchiv
2003
Dezember
 |
SELFHTML Forumsarchiv |
 |
|
 |
|
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 15:18
Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre. Schon in der Vergangenheit habe ich darauf hingewiesen, dass das Konzept von HTML nicht vorsieht, solche Navigationsleisten einzusetzen, da die Navigation einerseits und hauptsächlich durch Hyperlinks im Text an dafür sinnvollen Stellen und andererseits, innerhalb der Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«), durch Links, die mittels <link> definiert sind, zu erfolgen hat.
Da diese Möglichkeit durch die derzeitige Dominanz von Browsern, die diese Möglichkeit nicht oder nur unzureichend bieten, nur eingeschränkt möglich ist (in weiten Teilen des WWW allerdings sehr wohl, siehe meine Seiten abgesehen von den Blindtexten), ist diese Ansicht nicht für die Praxis relevant.
Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder ausgerichteten Elementen (»CSS-Layout«) umzusetzen. Die Entscheidung, ob Tabellen oder eben diese Techniken eingesetzt werden, hat daher nicht anhand von semantischen Maßstäben zu erfolgen, sondern einzig und allein anhand des Benutzers, der Barrierefreiheit und der Browserunterstützung. Ich rate von der Benutzung von klassischen CSS-Layouts ab.
Dies ist eine Privatmeinung.
Die folgende Nachricht zum Thema stammt von: Jeena Paradies, 30. 12. 2003, 15:38
Hallo,
»» Ich rate von der Benutzung von klassischen CSS-Layouts ab.
Zu was rätst du dann?
Grüße
Jeena Paradies
--
Alkoholverbot in der gesammten Bamberger Innenstadt!
http://www.jeenaparadies.de/alkoholverbot/
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 17:56
Hallo!
»» »» Ich rate von der Benutzung von klassischen CSS-Layouts ab.
»» Zu was rätst du dann?
Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.
emu
Die folgende Nachricht zum Thema stammt von: Orlando, 30. 12. 2003, 18:12
Seas emu,
»» »» »» Ich rate von der Benutzung von klassischen CSS-Layouts ab.
»» »»
»» »» Zu was rätst du dann?
»»
»» Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.
ich frage mich, welchen Vorteil das bringt und vor allem wem. Wenn du Listen-Elemente für eine Anhäufung von Links als falsch empfindest, wie rechtfertigst du dann eine Tabelle? Oder ist einfach nur ohnehin schon alles wurscht?
Grüße,
Roland
--
http://www.nils.org.au/ais/web/resources/toolbar/
http://aktuell.de.selfhtml.org/tippstricks/css/drucklayout/
Die folgende Nachricht zum Thema stammt von: Jeena Paradies, 30. 12. 2003, 18:39
Hallo,
»» Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.
Welche konkreten Vorteile bietet diese einer Liste?
Grüße
Jeena Paradies
--
Alkoholverbot in der gesammten Bamberger Innenstadt!
http://www.jeenaparadies.de/alkoholverbot/
Die folgende Nachricht zum Thema stammt von: Jeena Paradies, 30. 12. 2003, 18:40
Hallo,
»» Welche konkreten Vorteile bietet diese einer Liste?
gegenüber einer Liste?
sollte es eigentlich heißen :-)
Grüße
Jeena Paradies
--
Alkoholverbot in der gesammten Bamberger Innenstadt!
http://www.jeenaparadies.de/alkoholverbot/
Die folgende Nachricht zum Thema stammt von: Andreas-Lindig, 30. 12. 2003, 15:41
Hallo emu,
»» [...]
»» Dies ist eine Privatmeinung.
hab' ich ja nochmal Schwein gehabt ;)
Gruß, Andreas
--
http://was-ist-das.andreas-lindig.de
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 17:58
Hallo!
»» »» Dies ist eine Privatmeinung.
»» hab' ich ja nochmal Schwein gehabt ;)
Weiter unten im Forum wird darum gestritten, inwiefern man betonen muss, dass es Gegenmeinungen gibt. Deswegen wollte ich klarstellen, dass es keinesfalls Konsens hier ist, die Dinge so zu sehen wie ich.
emu
Die folgende Nachricht zum Thema stammt von: Cheatah, 30. 12. 2003, 16:04
Hi,
»» Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre.
nein, nur die Begrifflichkeit. "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert; es ist eine Interpretation des Menschen, genau wie z.B. "Footer". Daher ist es absurd anzunehmen, es gäbe in einer dieser Techniken ein Äquivalent des Begriffes. Es gibt nur das, was dann vom Menschen zur Navigationsleiste interpretiert wird - und zwar (i.d.R.) eine positionierte, ungeordnete Liste von Links.
Für diese Begriffe gibt es in HTML, CSS etc. Äquivalente.
»» Dies ist eine Privatmeinung.
Dies ist meine fachliche Meinung.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 18:02
Hallo!
»» "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;
Natürlich nicht. Aber in der Realität des WWW existiert es an jeder Ecke.
Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen. Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.
emu
Die folgende Nachricht zum Thema stammt von: Cheatah, 30. 12. 2003, 18:06
Hi,
»» »» "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;
»» Natürlich nicht. Aber in der Realität des WWW existiert es an jeder Ecke.
klar, aber was soll das mit HTML, CSS & Co. zu tun haben?
»» Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen.
Da sind wir uns einig :-)
»» Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.
Sorry, aber das kann ich kein Stück nachvollziehen. Was ist falsch daran, das Richtige zu machen? Warum ist die Sicherheit nur Schein? Und wo soll es stören, richtig vorzugehen, anstatt auf Dinosauriern zu beharren?
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
Die folgende Nachricht zum Thema stammt von: wahsaga, 30. 12. 2003, 18:15
hi,
»» Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen. Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.
warum ist eine liste von links plötzlich keine liste mehr, nur weil sie auf jeder seite wiederholt wird?
gruss,
wahsaga
Die folgende Nachricht zum Thema stammt von: molily, 30. 12. 2003, 19:34
»» "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;
Nein, es existiert aber als Strategie der hypertextuellen Vernetzung.
»» es ist eine Interpretation des Menschen, genau wie z.B. "Footer".
Auch Footer müssen sterben, die dort gelieferten Informationen sind meist Metadaten, dafür existieren meta und link, die entsprechende Umsetzung dieser Daten ist Aufgabe eines guten Hypertextleseprogramms. Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.
»» Daher ist es absurd anzunehmen, es gäbe in einer dieser Techniken ein Äquivalent des Begriffes. Es gibt nur das, was dann vom Menschen zur Navigationsleiste interpretiert wird - und zwar (i.d.R.) eine positionierte, ungeordnete Liste von Links.
Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.
Die folgende Nachricht zum Thema stammt von: Cheatah, 30. 12. 2003, 23:15
Hi,
»» Auch Footer müssen sterben, die dort gelieferten Informationen sind meist Metadaten, dafür existieren meta und link,
hm, jein. Erstens liegt eine gewisse Betonung auf dem Wort "meist", und zweitens gibt es unterschiedlichste Arten von Footern, für die dies mehr oder weniger gilt. Wie dem auch sei, es sollte nur ein Beispiel sein, kein Argument.
»» Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.
Ich denke, darüber muss im Einzelfall noch mal geredet werden - nachdem der Begriff "Bestandteil" einer präzisen Definition unterzogen wurde ;-) Ist beispielsweise ein longdesc-Attribut bzw. die dahinter liegende Ressource ein Bestandteil?
»» Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.
Genau das sehe ich anders: Der logische Charakter ist die angesprochene Interpretation des Menschen, und nichts, was von HTML etc. gehandhabt[1] werden muss (darf?). Die Links einer Navigation unterscheiden sich höchstens in ihrer wiederkehrenden Ähnlichkeit (bemerke: nicht Gleichheit) in anderen Ressourcen von anderen Links, die z.B. auch innerhalb eines Fließtextes mit den Links der Navigation identisch sein können - und je nach subjektiver Definition des Begriffes ebenfalls Navigation sind, oder es eben nicht sind.
Ich kann allerdings verstehen, wenn Deine Ansicht durch die Überschneidungen typischer in Navigationen anzufindenden Links mit diversen <link>-Elementen geprägt ist. In dem Fall darf (IMHO) jedoch _nur_ jene Ansammlung der <link>-Elemente als Navigation bezeichnet werden, während die auf der Seite angesiedelten navigationsangeordneten Links schlicht und ergreifend eine ungeordnete Liste von Links sind, jedoch _keine_ Navigation. Redundant, ja, aber nicht unbedingt überflüssig.
Cheatah
[1] Damit ist explizit _nicht_ gemeint, eine entsprechende Struktur zu ermöglichen, wie z.B. ein <div id="navigation">.
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
Die folgende Nachricht zum Thema stammt von: molily, 31. 12. 2003, 15:36
»» »» Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.
»»
»» Ich denke, darüber muss im Einzelfall noch mal geredet werden - nachdem der Begriff "Bestandteil" einer präzisen Definition unterzogen wurde ;-)
Bei Abstracts ist es m.M.n. eindeutig. Von einer Hypertext-Auszeichnungssprache erwarte ich, dass solche Dokumentteile explizit in ihrer Funktion ausgezeichnet werden können, damit sie flexibel gemäß dieser Funktion verarbeitet werden können. Da HTML dies nicht bietet, ist höchstens description, tablesOfContents und abstract von Dublin Core angemessen, allerdings bekommen diese »Elemente« erst ihren Sinn, wenn sie Hypertext enthalten können, also direkt in (X)HTML einbettbar sind, der möglichst einem Kodierungsschema folgt. Aber bevor mir emu Reformismus vorwirft, muss ich sagen, dass ich nicht glaube, dass (X)HTML gerettet werden kann, indem Elemente aus dem Dublin-Core-Namespace verwendet werden, um Defizite auszugleichen.
»» Ist beispielsweise ein longdesc-Attribut bzw. die dahinter liegende Ressource ein Bestandteil?
Nein, wenn es eine eigenständige Ressource ist, ist es ein Extraknoten(*), der sich in der Hierarchie der Knoten verorten lässt. Es sollte eine bidirektionale Verbindung zwischen der Langbeschreibung und dem Kontext geben, in den das Bild eingebunden ist, und es existiert idealerweise nur diese Verbindung.
(* Nun könnte man sich darüber streiten, ob nicht alles Adressierbare ein Knoten ist und longdesc="#langbeschreibung" als Verweis zu einer Art Fußnote mit einem »Zurück zum Bild«-Link bereits ebenfalls ein eigenständiger Knoten ist. Genauso sind eingebettete Ressourcen ebenfalls eigenständig, zumindest technisch, nicht »kohäsiv geschlossen«.)
»» »» Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.
»»
»» Genau das sehe ich anders: Der logische Charakter ist die angesprochene Interpretation des Menschen, und nichts, was von HTML etc. gehandhabt[1] werden muss (darf?).
Die Sprache HTML erlaubt durch die Attribute rel und rev, den logischen Charakter eines Hyperlinks formal und maschinenlesbar im Markup unterzubringen und die Art der Beziehung von Dokumenten auzuzeichnen. Der logische Charakter entsteht dadurch, dass das referenzierte Dokument durch diese bedeutungsvollen Verweise in den Gesamthypertext einer Site eingeordnet wird. Hypertext ist in der Regel ohne diese Art von herausgearbeiteten Beziehungen nicht denkbar, insofern würde ich sagen, dass es eine Kernaufgabe von HTML ist, diese logischen Beziehungen auszuzeichnen.
Die Links einer Navigationsliste beziehen sich immer auf ganz bestimmte Knoten mit einem bestimmten Platz und einer bestimmten Bedeutung in der Sitehierarchie, landläufig mit rel="chapter" ausgezeichnet, in der Sekundärnavigation dann mit rel="section" und Tertiärnavigation mit rel="subsection". Die Zugehörigkeit des aktuellen Dokuments lässt sich dann noch weiter durch sibling, up/parent/dc:isPartOf und anders herum mit child/dc:hasPart und so weiter auszeichnen.
»» Die Links einer Navigation unterscheiden sich höchstens in ihrer wiederkehrenden Ähnlichkeit (bemerke: nicht Gleichheit) in anderen Ressourcen von anderen Links
Die Links der Navigation haben eine bestimmte Funktion und eine bestimmte Bedeutung für das aktuelle Navigation, die andere Links im Dokument nicht haben.
»» die z.B. auch innerhalb eines Fließtextes mit den Links der Navigation identisch sein können - und je nach subjektiver Definition des Begriffes ebenfalls Navigation sind, oder es eben nicht sind.
Richtig, aber da ist ein gewaltiger Unterschied. In der Navigationsliste tauchen alle »Rubriken« der Seite auf, ganz gleich, ob sie im speziellen etwas mit dem Inhalt des jeweiligen Dokuments zu tun haben. Jedes Dokument der Site wird mit allen (zumindest Ober-)Rubriken der Site verknüpft. Dabei besteht nicht notwendigerweise ein direkter inhaltlicher Bezug. Die Rubriken können Themen behandeln bzw. Dokumente zu Themen gruppieren, die miteinander nichts zu tun haben, außer, dass sie einer Site angehören.
Wenn sich jedoch Links im Fließtext zu bestimmten Rubriken befinden, dann besteht in der Regel ein inhaltlicher Bezug. Diese Links stellen keine vollständige Liste der Rubriken dar, und wenn, dann macht der Fließtext spezielle Aussagen über die verlinkten Rubriken, die die Primärrubriklinkliste so nicht macht.
»» Ich kann allerdings verstehen, wenn Deine Ansicht durch die Überschneidungen typischer in Navigationen anzufindenden Links mit diversen <link>-Elementen geprägt ist.
Die Navigationsformen im Web sind nicht mannigfaltig, die meisten Hypertextstrukturen im Web sind ähnlich aufgebaut und arbeiten mit ähnlichen Techniken des Navigierens. Insofern beziehe ich mich und bezog sich offenbar emu auf sogenannte Primär-/Sekundär-/Tertiärrubriknavigationen (»Menüs«, Listen der [Unter-]Verzeichnisse bzw. [Unter-]Ordner), wie ich sie im Thread mehrfach geschildert habe. Diese können in all diesen Fällen durch <link rel="chapter/section/subsection"> ersetzt werden bzw. in Unterdokumenten weggelassen werden zugunsten fisheye-views in Form von link-Elementen (Verweise in der Hierarchie nach oben <link rel="parent chapter/section/subsection" rev="child dc:isPartOf"> und nach unten <link rel="section/subsection child dc:hasPart" rev="parent chapter/section">).
Die folgende Nachricht zum Thema stammt von: Armin G., 30. 12. 2003, 16:05
Tach auch,
»» Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre.
Tut sie? Oder koennte sie vielleicht zur Weiterentwicklung von HTML beitragen?
»» Schon in der Vergangenheit habe ich darauf hingewiesen, dass das Konzept von HTML nicht vorsieht, solche Navigationsleisten einzusetzen, da die Navigation einerseits und hauptsächlich durch Hyperlinks im Text an dafür sinnvollen Stellen und andererseits, innerhalb der Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«), durch Links, die mittels <link> definiert sind, zu erfolgen hat.
Nur ist in meinen Augen die Definition von <link> ziemlich unausgereift und undurchdacht. Verschiedene Unstimmigkeiten, unklare Definitionen usw, wie man ja an verschiedenen Diskussionen wofuer denn nun was benutzt werden sollte sehen kann. Je nachdem was Deine Definition von "Navigationsleiste" umfasst gibt es verschiedene Funktionen unter <link> nicht oder sie sind sehr schwammig beschrieben.
Ebenso wirft sich fuer mich die Frage auf ob das Konzept von HTML so wie Du es darstellst noch der Wirklichkeit und der Entwicklung wie das Web heutzutage benutzt wird mitgehalten hat. Oder anders gesagt, ist das Konzept noch zeitgemaess?
Der Ursprung waren wissenschaftliche Arbeiten, was sich ja ganz besonders am <link> Element sehr gut sehen laesst. Besteht das Web heutzutage vorwiegend aus wissenschaftlichen Arbeiten? Nein, weit entfernt davon.
»» Da diese Möglichkeit durch die derzeitige Dominanz von Browsern, die diese Möglichkeit nicht oder nur unzureichend bieten, nur eingeschränkt möglich ist (in weiten Teilen des WWW allerdings sehr wohl, siehe meine Seiten abgesehen von den Blindtexten), ist diese Ansicht nicht für die Praxis relevant.
Liegt das wirklich nur an den Browsern? Oder vielleicht auch an der schlechten Definition von <link>? Nicht zu vergessen der Weiterentwicklung des Webs?
»» Dies ist eine Privatmeinung.
Im Gegensatz zu was?
Der Meinung
- der Firma bei der Du arbeitest?
- der Uni an der Du studierst?
- des Mobs im SelfForum?
- des W3C?
Gruss,
Armin
--
Location: Swindon/Wiltshire/England/UK/Europe/Northern Hemisphere/Planet Earth/Solar System/Milky Way Galaxy/Universe
http://www.ministryofpropaganda.co.uk/
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 18:08
Hallo!
»» Nur ist in meinen Augen die Definition von <link> ziemlich unausgereift und undurchdacht.
Ja. Insofern ist das Element auch nur beschränkt einsatzfähig, das ändert jedoch nichts an meiner Argumentation, dass es nämlich letztlich egal ist, ob man »Tabellen oder CSS« für den »Seitenaufbau« verwendet.
»» Ebenso wirft sich fuer mich die Frage auf ob das Konzept von HTML so wie Du es darstellst noch der Wirklichkeit und der Entwicklung wie das Web heutzutage benutzt wird mitgehalten hat.
Die Inhalte haben sich an das Medium zu halten, nicht das Medium an die Inhalte. Leider ist das Gegenteil derzeit der Fall.
emu
Die folgende Nachricht zum Thema stammt von: Armin G., 30. 12. 2003, 18:12
Tach auch,
»» Die Inhalte haben sich an das Medium zu halten, nicht das Medium an die Inhalte. Leider ist das Gegenteil derzeit der Fall.
Das sehe ich genau andersherum. Das Medium sollte sich weiterentwickeln und neuen Inhalten die Gelegenheit geben sich zu entfalten. Ansonsten bleibt nur Stagnation.
Gruss,
Armin
--
Location: Swindon/Wiltshire/England/UK/Europe/Northern Hemisphere/Planet Earth/Solar System/Milky Way Galaxy/Universe
http://www.ministryofpropaganda.co.uk/
Die folgende Nachricht zum Thema stammt von: at, 30. 12. 2003, 23:54
Hallo.
»» Ansonsten bleibt nur Stagnation.
Ich muss dich beunruhigen: Stagnation bleibt in jedem Fall ;-)
MfG, at
Die folgende Nachricht zum Thema stammt von: Chräcker Heller, 30. 12. 2003, 19:46
Hallo,
»» Die Inhalte haben sich an das Medium zu halten
Es ist genau auch dieses Denken der eher technik und Theorielastigen Entwickler des freien Standards im Web das dazu führte, das das Medium "aneinandergeschlossene Computer die Tag und Nacht weltweit angeschaltet sind" in vielen Anwendungsfällen nur noch von kommerziell ausgerichteten Firmen weiterentwickelt wird. Die meisten Techniken neben(!) html wurden von Firmen als in sich gekapselte Lösungen entwickelt, wie eben das viel geschmäte Flash. Die freien Pendants dümpeln was die Comsumerfreundlichkeit angeht, weit hinterher. Man hat ja html und habe sich daran zu halten. Das ist nicht nur unsinnig der Entwicklung gegenüber sondern was die Qualitätsicherung von html-Seiten angeht auch geradezu kontraproduktiv. Html würde viel weniger schlecht eingesetzt, wenn es für die gewünschten Einsatzmöglichkeiten ebenfalls weit entwickelte freie Alternativtechniken gäbe.
Wie gut das es einige Menschen gab, denen der Stummfilm nicht ausreichte und sich nicht sagten: "unsere Inhalte haben sich an das Medium zu halten."
Chräcker
--
http://www.Schubladendinge.de
zu:]
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 03. 01. 2004, 20:39
Hallo Chräcker,
»» Es ist genau auch dieses Denken der eher technik und Theorielastigen
»» Entwickler des freien Standards im Web das dazu führte, das das Medium
»» "aneinandergeschlossene Computer die Tag und Nacht weltweit angeschaltet
»» sind" in vielen Anwendungsfällen nur noch von kommerziell ausgerichteten
»» Firmen weiterentwickelt wird.
Diese Behauptung halte ich in Teilen für unsinnig. Zum einen weil die
Strukturen des Internet, wie wir es kennen, das WWW eingeschlossen, im
Großteil von der wissenschaftlichen Gemeinde und von Privatpersonen
entwickelt wurde, also das, was man am ehesten bei freien Standards
assoziert. Aber auch die anderen Standards, die von Firmen entwickelt
wurden und sich größtenteils durchgesetzt haben, sind als frei zu
betrachten. Viele der vom W3C empfohlenen Standards haben ihren Ursprung
in Firmen, schließlich ist das W3C (und andere internationale Gremien
zur Standardisierung) ein Industriekonsortium. Der Gedanke dahinter
scheint mir zu sein, daß ein größerer Markt entstehen kann, wenn die
Spezifikation frei ist, die Produkte jedoch unterschiedlich sind und
das dies unter dem Strich betrachtet mehr bringen kann als eine
Insellösung. Wobei Microsoft als Quasi-Monopolist gesondert zu
betrachten ist, gebe ich gerne zu.
Größere Firmen leisten sich dafür Deine theorielastigen Entwickler.
Weil diese stark theoretische Arbeit geleistet doch geleistet werden
muß und die Forschungen an Universitäten eher in die andere Richtung
gehen. Also macht es die Privatwirtschaft, entweder eigens dafür
angestellte Leutchen in größeren Firmen oder nebenbei Entwickler in
den kleineren. (Joel von Joel On Software hat diese Entwickler mal mit
dem schönen Begriff "Architecture Astronauts" bezeichnet. Könntest Du
glatt übernehmen, nicht? ;)
Zum Beispiel: Javascript. Es wurde von Netscape entwickelt, von Microsoft
in den Browserwars nach dem VBScript-Desaster als JScript kopiert. Dann
hat Netscape die Basis als ECMAScript von der ECMA standardisieren lassen
und so wie es aussieht basieren jetzt Javascript und JScript beide auf
ECMAScript. Und Du lebst nicht schlecht damit, oder? ;-)
(Jetzt besser überspringen)
Zum (ausgedehnteren) Beispiel: Das unter Weblogautoren im Moment so
beliebte XML-Format RSS.
In der Mitte der 90er entwickelte ein Kerl namens Guha für Apple ein
Format namens MCF. Dann wechselte er zu Netscape und sollte dort dieses
Format weiterentwickeln, weil Microsoft mit dem CDF ein XML-Format auf
dem Markt rollte. Nebenbei: XML ist ein freier Standard, der unter der
Schirmherrschaft des W3Cs von Microsoft und Sun mitentwickelt wurde.
Eine Verschmelzung von MCF und XML ging dann als Vorschlag an das W3C.
Aus XML-MCF entwickelte sich unter Netscape dann RSS 0.9. Gleichzeitig
entwickelte David Winer für seine eigene Firma Userland am Beispiel des
Formates CDF sein ScriptingNews-Format. Dieses entwickelte er dann,
immer noch für seine Firma zu RSS 0.91 und dessen Nachfolgern weiter.
Gleichzeitig wurde RSS 0.9 von einer Working Group des W3C weiterentwickelt,
im Kernteam von Leuten, die diversesten Firmen angehören (So zum Beispiel
O'Reilly, um die bekannteste zu nennen), aber die Entwicklungsmailingliste
war für jeden offen. Man wollte RSS 0.9 mit dem anscheinend an XML-MCF
angelehnte Metadatenformat RDF (Unter der Schirmherschaft des W3Cs von
eine Nokia-Angestellten entwickelt) darin einbringen und dies natürlich
mit den später zur XML Spezifikation hinzugefügten Namespaces (Eine
Spezifikation von HP und Microsoft Angestellten). So entstand RSS 1.0.
Dave Winer von Userland, obwohl am Anfang mitwirkend war damit unzufrieden
und veröffentlichte für seine Firma RSS 2.0, in dem der die Möglichkeit
der Namespaces mit übernahm. Später stellte er diese Spezifikation wegen
einiger öffentlicher Proteste (Es gibt viele politische Differenzen um RSS)
unter die Schirmherrschaft der Rechtsfakultät der Universität Harvard.
(Jetzt bitte wieder anfangen zu lesen)
Was will ich mit dem ganzen Wust sagen? Freie oder besser offene Standards
sind keine Domäne von irgendwelchen idealistischen Privatpersonen. Sie
werden von Theoretikern angedacht und von etwas pragmatischeren Jungs in
tatsächliche Standards umgesetzt. Und all diese sind von Firmen angestellt,
die sich in Gremien zu Standardisierung, seien es institutionalisierte,
seien es unformelle wie das Wiki zu Entwicklung vom RSS-Konkurrenten Atom
engagieren. Es gibt einen langfristigeren Trend hin zu offeneren Standards,
die Märkte für Produkte und Services entstehen lassen. Zähl mal alleine die
Zahl der kommerziellen und nicht-kommerziellen Produkte, die RSS ausspucken
und konsumieren können. Und oft schafft dies mehr als proprietäre
Insellösungen.
»» Die freien Pendants dümpeln was die Comsumerfreundlichkeit angeht, weit
»» hinterher.
Ich sehe ein Hinterherdümpeln in der Technologie- und Marktdurchsetzung.
Aber in der Consumerfreundlichkeit?
»» Man hat ja html und habe sich daran zu halten.
Ich sehe niemanden, der eine Weiterentwicklung blockieren würde. (Das mit
dem daran zu halten spare ich mal aus, angesichts der Erfahrungen aus den
Browserkriegen der 90er dürfte das so langsam als Selbstverständlichkeit
ins Bewußtsein einfließen. Schließlich sind es Standards) Aber wo siehst
Du eine Blockadementalität gegen Weiterentwicklung?
»» (..) wenn es für die gewünschten Einsatzmöglichkeiten ebenfalls weit
»» entwickelte freie Alternativtechniken gäbe.
Die gibt es. Sie haben es aber noch nicht wirklich als Implementierung
wirklich in den Markt gebracht, einfach weil der Platz schon teilweise
besetzt ist. Aber schau Dir mal an, was Thomas Meinike da für Dinge mit
SVG macht. Guck Dir an, was mit PNG geschieht.
»» Wie gut das es einige Menschen gab, denen der Stummfilm nicht ausreichte
»» und sich nicht sagten: "unsere Inhalte haben sich an das Medium zu
»» halten."
Um nochmal zum Threadthema zurückzukehren: Ich glaube hier mißverstehst
Du emu, auch wenn dieser sich recht kontrovers und missverständlich
ausgedrückt hat. Wenn das Medium aus naheliegenden Gründen einem
technischen Standard zu folgen hat, kann ein durch Inhalte bedingter
Bruch dieses Standards im Gegensatz zu Brüchen in kompromissbereiteren
Medien recht chaotische Züge an sich nehmen. Es hat seinen Grund,
weswegen es einen Standard gibt.
In Beispielen: Eine Buchseite verdaut es wunderbar, wenn statt des von
Gutenberg inspirierten Einheitsdruck plötzlich ein Textkunstwerk von
Jandl zu sehen ist. Ein Filmprojektor kriegt arge Schwierigkeiten, wenn
der Regisseur plötzlich meint statt in 35mm Film in 47,8mm-Film filmen
zu müssen. Nicht, daß keine standardisierte Weiterentwicklung in diesem
Bereich existieren würde; es gibt entsprechendes in Industriekonsortien
entwickeltes (HighDefinition, THX und wie es alles heißt). Aber auch das
muß sich am Markt durchsetzen.
emus Satz ist recht kontrovers zu sehen. Ich persönlich neige mich so
langsam einer eher pragmatischen Sichweise zu, könnte aus der prinzipiellen
Ecke aber nicht wirklich etwas dagegen sagen.
Denn schließlich: In diesem Thread geht es nicht um den tatsächlichen
Alltag, sondern um Utopien. Wir Architekturastronauten, wir.
Tim
--
Meine persönlichen Utopien bräuchten zum Beispiel ein Grafikprogramm,
recht viel Zeit und genauer ausformulierte Ideen zum umgestalten der
Browsermetapher.
Die folgende Nachricht zum Thema stammt von: Chräcker Heller, 30. 12. 2003, 16:11
Hallo,
mir ist nicht klar worüber Du redest. Überspitzt formuliert (und bitte nur so überspitzt sehen) Redest Du von Navigationsstrukturen in Spielemenüs? Im Bedienmenü von Textverarbeitungen? Oder von "Besuchergesteurten" Filmpräsentationen?
Ich weiß natürlich, und damit federe ich die Überspitzung wieder etwas ab, das Du natürlich Präsentationen innerhalb des Netzes meinst. Aber hier ist die Welt mindestens genauso vielfältig. Auch weiß ich, um "mich" weiter zurück zu nehmen, das Du das Themengebiet HTML angesprochen hast. Allerdings wird die Auszeichnungssprache nicht nur für reine semantisch korekt aufgebaute Hypertexte genutzt. Das hat auch etwas damit zu tun, das die Entwicklung "Projektgerechtere" Techniken und vor allem die Verbreitung entsprechender Zugangssoftware sich noch nicht so durchsetzen konnte. (was auch daran liegt, das die technikvorantreibende Fraktion eben tendenziell eher diesen alternativen Techniken skeptisch gegenüber stehen....)
Man kann also aus der Nutzung der Auszeichnungsprache html nicht davon ausgehen, das nacher auch reine html-Seiten erwünscht oder gar zweckmässig sind. Solange es noch keinen Schraubenzieher gibt, nehmen eben nicht wenige die Rohrzange um die Schraube rein zu bekommen. Natürlich mit den gleichen negativen Nebenwirkungen.
Deswegen kann ich solch paiuschale Aussagen, wie man "mit html" nun dies und das allein richtig zu tun hat nur sehr bedingt nachvollziehen.
Dies ist eine Privatmeinung.
Chräcker
--
http://www.Schubladendinge.de
zu:]
Die folgende Nachricht zum Thema stammt von: emu, 30. 12. 2003, 18:13
Hallo!
»» mir ist nicht klar worüber Du redest.
Ich rede von dem, was klassischerweise als Navigationsleiste bezeichnet wird, eine projektintern an einer bestimmten Stelle und mit einem bestimmten, von Seite zu Seiten entweder gar nicht oder nicht strukturell Inhalt. Das ist in der Regel eine Spalte links oder oben, manchmal beides.
Der Sinn meines Postings war einzig und allein (und diese Aussage dürfte dir sehr entgegenkommen, ist es doch das, was du seit Jahr und Tag predigst): Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.
Wer argumentiert, Layout-Tabellen seien böse, weil unsemantisch, und daher durch klassische »CSS-Layouts« zu ersetzen, irrt. Meiner Meinung nach.
emu
Die folgende Nachricht zum Thema stammt von: wahsaga, 30. 12. 2003, 18:22
hi,
»» Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.
mir leuchtet immer noch nicht ein, warum für dich eine liste von links nicht auch semantisch eine liste ist.
»» Wer argumentiert, Layout-Tabellen seien böse, weil unsemantisch, und daher durch klassische »CSS-Layouts« zu ersetzen, irrt. Meiner Meinung nach.
meiner meinung nach nicht.
wenn du die navigation einer seite in tabellenform aufbaust, ist das m.E. noch halbwegs korrekt. es handelt sich nun mal um daten gleicher art, nämlich links zu verschiedenen (unter-)seiten. (allerdings dürfte man dann streng genommen nur jeden link in eine einzelne <tr> packen, denn zwischen zwei links besteht ja von der datenart her kein derartiger unterschied, dass sie in zwei nebeneinander liegende <td> gehören würden.)
das ändert doch aber nichts daran, dass es wenig sinnvoll ist, eine tabelle zum layouten zu verwenden, wenn man damit lediglich eine "korrekte" _positionierung_ von header/inhalt/footer/... erreichen will. zwischen _diesen_ elementen besteht nämlich kein zwingender logischer zusammenhang bzw. eine gleichartige datenstruktur.
gruss,
wahsaga
Die folgende Nachricht zum Thema stammt von: molily, 30. 12. 2003, 19:13
»» »» Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.
»»
»» mir leuchtet immer noch nicht ein, warum für dich eine liste von links nicht auch semantisch eine liste ist.
Es geht nicht um Listen im Allgemeinen, es geht um Navigationslisten, ich würde sie Primär- und Sekundärnavigationen nennen, die die sogenannten Hauptrubriken bzw. thematisch geordneten Verzeichnisse (»Ordner«, wobei ich diese Symbolik im Grunde für lächerlich halte, aber wie auch immer) abbilden sowie site-zentrale Einrichtungen wie Glossar, Index, Suche, Kontakt, Hilfe, Sitemap, Impressum usw. zugänglich machen. All diese Verknüpfungen sind nicht assoziativ und haben keine konkrete Verbindung zum Inhalt, sondern umschreiben die Struktur des Hypertextes, also die umliegenden Knoten, in den das Dokument eingebunden ist. Sie sind nicht der Knoten an sich und sind nur begrenzt Kontextbildner (im Vergleich zu assoziativen Querverbindungen). All diese Verknüpfungen sind formalisiert mit maschinenlesbaren link-Elementen auszuzeichnen, die weitesgehend alle Navigationsschritte in Hierarchie und Sequenz abdecken.
Aus einem anderen Posting von emu /archiv/2002/5/12885/#m71213:
»Das Konzept von HTML sieht doch ein Menü an sich gar nicht vor. Blättern, Glossar, Inhaltsverzeichnis, Anfänge von Kapitel und Projekt, Copyright und haufenweise mehr lässt sich durch Verwendung von <link> machen. Die Meta-Angaben weisen den Autor und noch einige wichtige andere Dinge aus. Von der einen Seite zur anderen sind im eigentlichen Dokument nur sinnhafte Links, die einen logischen Bezug zum Text haben [!], notwendig, denn der eigentliche Hypertext macht keinen Unterschied zwischen verschiedenen Projekten.«
Die folgende Nachricht zum Thema stammt von: Chräcker Heller, 30. 12. 2003, 19:38
Hallo,
ich habe ja nie was dagegen, wenn jemand meine unausgegorene und nicht selten über Ziel schiessende Bauchmeinung nacher mit Wissen hinterlegt, eine Praxiz, die ja hier nicht selten zu netten Schulterschlüssen führt ;-)
Was ich wissen möchte war nur: wer sagt, das ein Navigationsbereich/Navigationsleiste oder wie auch immer semantisch nur "richtig", wenn sie in einer bestimmten Technik eingearbeitet wurde? Kann ich anhand der eingesetzten Technik ersehen, ob ein Menü in meinem neuen PC-Spiel nun semantisch richtig ist? (Auch wenn es ein Spiel ist, das ich per html übers Web auf die Browseroberfläche bringe....) Ist die zugrundegelegte Technik für das semantische Verständnis des Nutzers (hier Spieler) nur dann richtig, wenn es mit einer bestimmten Technik hinterlegt wurde? Wo ist nun der Unterschied eines Menüs in einem Spiel, in einem Grafikprogramm oder auf einer Webseite? Ich glaube zu wissen, wo der unterschied in Deinem "Betrachtungsfall" ist (Du meinst wohl das, was ich immer gerne und nicht herablassend sondern eher würdigend als "reinrassige html-Seiten" nenne), aber dieser Unterschied wurde mir ein klitzeklein zu wenig herausgestellt. (oder ich habe es überlesen, kann natürlich gut sein)
Chräcker
--
http://www.Schubladendinge.de
zu:]
Die folgende Nachricht zum Thema stammt von: Cyx23, 30. 12. 2003, 22:04
Hallo,
»» Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder ausgerichteten Elementen (»CSS-Layout«) umzusetzen.
die Möglichkeit deine Vorstellung von HTML mit Anforderungen an Barrierefreiheit und Browserunterstützung alltagstauglich zu verbinden bietet allerdings besonders das Frameset.
Ansonsten sind viele derartige Betrachtungen grundsätzlich fragwürdig weil meist weder beim Rezipienten noch beim Autor solche einseitige "semantische Sicht" einen Nutzen bringt.
Auch der Ansatz einer klaren Trennung von Form und Inhalt oder selbst von GUI und angezeigter Seite ist als Hilfmittel zur Analyse zwar nützlich, aber deswegen nicht automatisch legitim oder richtig.
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: molily, 31. 12. 2003, 15:27
»» die Möglichkeit deine Vorstellung von HTML mit Anforderungen an Barrierefreiheit und Browserunterstützung alltagstauglich zu verbinden bietet allerdings besonders das Frameset.
Im Gegenteil, Framesets führen dazu, dass Verknüpfungen eines Dokuments mit den umliegenden Knoten der Sitehierarchie gar nicht mehr explizit ausgedrückt werden. Ein Verzeichnisdokument aka »Navigationsframe« ist wieder nichts anderes als eine Primär- und Sekundärnavigation, und dass sie vollkommen und ersatzlos ausgelagert wird, ist nur ein Nachteil und in der Regel so unsemantisch wie es nur geht.
Wie wird bei einem Frameset kommuniziert, wie sich das Dokument in die umliegende Struktur einfügt? Etwa durch den Framekontext, ohne den alle Verbindungen des Dokuments zum Kontext der Sitehierarchie gekappt sind?
»» Ansonsten sind viele derartige Betrachtungen grundsätzlich fragwürdig weil meist weder beim Rezipienten noch beim Autor solche einseitige "semantische Sicht" einen Nutzen bringt.
Im Gegenteil, emu kritisiert die einseitige semantische Sicht, die sich mit den Fragen aufhält, ob Tabelle oder CSS angemessen sind, um eine Primärrubriknavigation in einer bestimmten Weise zum Hauptinhalt anzuordnen. emu ging es aber darum, dass diese Verzeichnisse nichts im Dokument verloren haben und alle Kontextverweise der Hierarchie (top-parent-*-child) und der Sequenz (first-prev-*-next-last) über link ausgezeichnet werden. Die richtige Markupstruktur, um ein klassisches »Menü« zu realisieren, wäre also höchstens <link rel="chapter href="1"><link rel="chapter" href="2"><link rel="chapter" href="2">...<link rel="chapter" href="n"> im rev="top"-Dokument.
»» Auch der Ansatz einer klaren Trennung von Form und Inhalt oder selbst von GUI und angezeigter Seite ist als Hilfmittel zur Analyse zwar nützlich, aber deswegen nicht automatisch legitim oder richtig.
Was ist die Trennung von GUI und angezeigter Seite?
Es geht hier übrigens nicht um Alltagstauglichkeit, sondern darum, dass wirkliche Semantik in diesem Punkt nie erreicht werden kann, man also nie davon sprechen kann, dass das, was man landläufig als »Navigation« versteht, semantisch umgesetzt sein kann, weil diese Vorstellung per se unsemantisch ist. Das System ist Schuld.(tm)
Die folgende Nachricht zum Thema stammt von: emu, 31. 12. 2003, 15:37
Hallo!
»» Es geht hier übrigens nicht um Alltagstauglichkeit, sondern darum, dass wirkliche Semantik in diesem Punkt nie erreicht werden kann, man also nie davon sprechen kann, dass das, was man landläufig als »Navigation« versteht, semantisch umgesetzt sein kann, weil diese Vorstellung per se unsemantisch ist.
Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.
emu
Die folgende Nachricht zum Thema stammt von: at, 01. 01. 2004, 14:13
Hallo.
»» Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.
In einem eigenen <frame> könnten Navigationsleisten gleichbedeutend mit und auch visuell ähnlich einer Sitemap sein, deren semantischer Gehalt mir nicht fragwürdig scheint, wenn sie ein eine abgeschlossene Informationseinheit innerhalb eines einzelnen Dokumentes darstellt. Genau das ist bei Frames der Fall, was mich allerdings in keinster Weise dazu verleiten könnte, diese Technik zu verwenden. Mir genügt stattdessen eine inhaltliche Abschirmung mittels ID und eine visuelle Abtrennung als Ergänzung einer weitreichenden Hypertext-Struktur. So habe ich erst vor kurzem unter anderem die Straßenangaben auf Kontaktseiten und im Impressum mit Verweisen auf die Anfahrskizze versehen. Um aber der plötzlichen Eingebung eines Nutzers nicht entgegenzustehen, wenn er sich während des Lesens einer völlig anderen Seite fragt, wie er physisch zum Autoren gelangen könnte, biete ich ihm diese Möglichkeit natürlich auch weiterhin auf allen Seiten. Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.
MfG, at
Die folgende Nachricht zum Thema stammt von: molily, 08. 01. 2004, 18:56
»» »» Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.
»»
»» In einem eigenen <frame> könnten Navigationsleisten gleichbedeutend mit und auch visuell ähnlich einer Sitemap sein, deren semantischer Gehalt mir nicht fragwürdig scheint,
Die im Sitemap-Frame gezeigten Links haben nicht notwendigerweise etwas mit dem Inhalt des Dokuments zu tun. Das ist wie gesagt derselbe Rückschritt gegenüber dem Anspruch, die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten.
»» Um aber der plötzlichen Eingebung eines Nutzers nicht entgegenzustehen, wenn er sich während des Lesens einer völlig anderen Seite fragt, wie er physisch zum Autoren gelangen könnte, biete ich ihm diese Möglichkeit natürlich auch weiterhin auf allen Seiten.
Wie ich bereits in [pref:t=67816&m=388377] beschrieben habe, sind Links auf solche site-zentralen Dokumente tatsächlich von jedem Knoten der Seite aus relevant, um schnelle Zugänglichkeit zu ermöglichen. Insofern würde es in das Konzept mit link passen, auch wenn mir gerade kein eindeutiger Relationstyp vorschwebt. Hier in Selfhtml wird in solchen Fällen rel="bookmark" verwendet, allerdings bedeutet das gemäß den Specs eigentlich etwas anderes (http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html#bookmark).
»» Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.
Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.
Die folgende Nachricht zum Thema stammt von: at, 08. 01. 2004, 21:34
Hallo.
»» Die im Sitemap-Frame gezeigten Links haben nicht notwendigerweise etwas mit dem Inhalt des Dokuments zu tun.
Nein, sie stellen ja auch eine geschlosse Einheit dar, nämlich eine eigenständige Seite.
»» Das ist wie gesagt derselbe Rückschritt gegenüber dem Anspruch, die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten.
In diesem abgeschlossenen Dokument geht es aber ausschließlich um diese Knoten.
»» »» Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.
»»
»» Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.
Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.
MfG, at
Die folgende Nachricht zum Thema stammt von: Cyx23, 10. 01. 2004, 13:17
Hallo,
»» »» Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.
»»
»» Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.
der Autor wird oder kann seine Aussage anhand der Wirkung seiner Präsentation überprüfen, ggf. überprüfen lassen.
Wenn sich natürlich Kultur und Sprache ändern wie etwa nach der Rechtschreibreform bedarf es erneuter Überprüfung und ggf. Übersetzung.
Ähnlich könnte eine Änderung der Darstellung berücksichtigt werden, so die dichteren Pixel bei 17" TFTs, selbst wenn zunächst Sinnänderungen wenig plausibel scheinen.
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: at, 10. 01. 2004, 16:32
Hallo.
»» »» Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.
»»
»» der Autor wird oder kann seine Aussage anhand der Wirkung seiner Präsentation überprüfen, ggf. überprüfen lassen.
Wenn ihm etwas an seiner Sichtweise liegt, wird er dies tun, ja.
»» Wenn sich natürlich Kultur und Sprache ändern wie etwa nach der Rechtschreibreform bedarf es erneuter Überprüfung und ggf. Übersetzung.
Im Prinzip hast du Recht, aber diese Veränderungen sind ja eher schleichender Natur. Außerdem kenne ich persönlich sie mehr in Bezug auf einzelne Begriffe (Paradebeispiel: "geil") als in Bezug auf die Struktur eines Dokumentes.
»» Ähnlich könnte eine Änderung der Darstellung berücksichtigt werden, so die dichteren Pixel bei 17" TFTs, selbst wenn zunächst Sinnänderungen wenig plausibel scheinen.
Die derzeitigen Mittel scheinen mir darauf nicht ausgelegt zu sein. Mit "em", "ex" oder "%" zu arbeiten ist sicher ein Anfang, aber das Skalieren von Bildern diesen Techniken und damit den Browsern zu überlassen, halte ich für derzeit wenig hilfreich. Jenseits deines Beispiels ist die Berücksichtigung sehr unterschiedlicher Medien aber sicher sinnvoll, etwa für Westentaschen-Computer, web-Taugliche Armbanduhren etc.
Das prinzipielle Problem wird also bleiben, dass sich der Autor mit seinen Inhalten, deren Wirkung, seiner Absicht und der der Präsentation zu Grunde liegenden Technik noch eingehender befassen muss -- gerade in Hinblick auf das semantische Web.
MfG, at
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 02. 01. 2004, 03:24
»» Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung
»» aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus
»» semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder
»» ausgerichteten Elementen (»CSS-Layout«) umzusetzen.
Der derzeitige Mißbrauch von generellen Listen zu Navigationszwecken dürfte
ein Übergangsverhalten zu dem Navigationslistenelement in XHTML 2 sein. Es
scheint aber noch unklar zu sein, ob <nl> im Dokumentenkopf oder im
Dokumentenkörper angesiedelt sein wird, noch, was es enthalten darf.
http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl
Dies wurde mir von dem kleinen, grünen Männchen ins Ohr geflüstert, das
links auf meiner rechten Schulter sitzt und hat nichts mit meinen
privaten Utopien zu tun.
--
Neuer Trend unter molilys Jüngern: Sich nicht begrüßen oder verabschieden.
Jetzt aufgreifen, ehe es zu spät ist! Siehe Flashmobs.
Die folgende Nachricht zum Thema stammt von: emu, 02. 01. 2004, 18:57
»» Der derzeitige Mißbrauch von generellen Listen zu Navigationszwecken dürfte
»» ein Übergangsverhalten zu dem Navigationslistenelement in XHTML 2 sein.
Ein neuer Kompromiss, das braucht die Welt, besonders in einer Auszeichnungssprache, die ausdrücklich nicht mehr kompatibel zu vorhergehenden Versionen sein will. Hurra!
--
Semantik?
Sehr lobenswert, ich bin auch dafür.
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 03. 01. 2004, 17:53
Hallo,
»» Ein neuer Kompromiss, das braucht die Welt, besonders in einer
»» Auszeichnungssprache, die ausdrücklich nicht mehr kompatibel zu
»» vorhergehenden Versionen sein will. Hurra!
XHTML 2 leidet eindeutig darunter, daß es XHTML 2 ist. Allerdings: Die
Kombination URI/HTTP dient ja nicht nur für HTML und ähnliches. Das
HTTP-Modell funktioniert auch prima mit anderen Ansätzen, wenn man sich
man die REST-Initiative ansieht. Interessant war für mich zu beobachten
wie man sich im Atom-Wiki mit dem Syndication-Format und der API recht
auf die ursprünglichen Gedanken zurückbesonnen hat, wohl auch ein Effekt
der üblichen teilnehmenden puristischen Apologeten und Evangelisten. Ab
und an sollte man sich tatsächlich erinnern, daß HTML nur eine ausgelieferte
Erscheinungsart einer Ressource sein kann. Wobei ich den Grand Unified
Browser in den nächsten zehn oder mehr Jahren nicht sehe, nicht mal eine
eventuelle Unterstützung für RDF.
Tim
--
Trotzdem wird Marc Andreesen bei der Revolution an die Wand gestellt.
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 03. 01. 2004, 20:51
Hallo emu nochmal,
»» (..) Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«)
»Eigentlich« gibt es keine Webpräsenzen, es gibt nur Ressourcen.
Die folgende Nachricht zum Thema stammt von: emu, 04. 01. 2004, 15:42
Hallo!
»» »» (..) Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«)
»» »Eigentlich« gibt es keine Webpräsenzen, es gibt nur Ressourcen.
Da hast du recht, aber du ahnst ja nicht, wie oft ich diesen Teil umformuliert habe. Schließlich habe ich mich für Anführungszeichen, die noch von Klammern beschützt werden, entschieden und ausdrücklich darauf hingewiesen, dass [nur] der Autor die Seiten als zusammengehörig sieht. Das wäre ja schon wieder das nächste Problem, dass im WWW gerade von Extremisten in den dafür vorgesehenen Newsgroups Seiten, die nicht im entferntesten zusammen gehören, in ein einheitliches »Design« gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische Logik und im übrigen böse[tm].
Das werde ich in der Newsgroup, die wir alle kennen, auch noch einmal schreiben, aber derzeit habe ich keinen Nerv auf Flamewars.
emu
--
Tim lernt schnell. Bald wird er seinen Guru überrunden.
Gut, dass es Wettbewerb unter den Molilysten gibt!
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 04. 01. 2004, 16:03
Hallo emu,
»» Das wäre ja schon wieder das nächste Problem, dass im WWW (..) Seiten, die
»» nicht im entferntesten zusammen gehören, in ein einheitliches »Design«
»» gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist
»» ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische
»» Logik und im übrigen böse[tm].
Es gibt immer noch das Konzept der Domäne, die einen einzelne Einheit
im Web/Netz repräsentiert. Wäre eine mögliche Rechtfertigung. Eine
andere ist natürlich die, daß mehr oder minder zentrale, möglichst
geprüfte Stylesheets besser sind als ad hoc erstellte. Ausnahmen bestätigen
irgendwelche Regeln.
»» Das werde ich in der Newsgroup, die wir alle kennen, auch noch einmal
»» schreiben, aber derzeit habe ich keinen Nerv auf Flamewars.
Oh, sollte ich tatsächlich mal wieder Halimé anschmeißen müssen?
Tim
--
Neues Jahr, neue Distinktionsbemühungen.
Die folgende Nachricht zum Thema stammt von: Cyx23, 06. 01. 2004, 12:14
Hallo,
»» »» Das wäre ja schon wieder das nächste Problem, dass im WWW (..) Seiten, die
»» »» nicht im entferntesten zusammen gehören, in ein einheitliches »Design«
»» »» gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist
»» »» ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische
»» »» Logik und im übrigen böse[tm].
»»
»» Es gibt immer noch das Konzept der Domäne, die einen einzelne Einheit
»» im Web/Netz repräsentiert. Wäre eine mögliche Rechtfertigung. Eine
»» andere ist natürlich die, daß mehr oder minder zentrale, möglichst
»» geprüfte Stylesheets besser sind als ad hoc erstellte. Ausnahmen bestätigen
»» irgendwelche Regeln.
was meint hier "nicht im entferntesten zusammen gehören"?
Oft ist es ja sowieso die Umsetzung einer Corporate Identity durch verschiedene Bereiche gewünscht, und bei CI geht es nicht nur um Marketing, CI kann den Kundenkontakt verbessern oder auch intern Vorteile haben. Hinsichtlich der Navigation ist ja Gleichförmigkeit i.d.R. auch vorteilhaft.
"einheitliches »Design«" meint wohl einheitliches Layout als Designleistung, da ist die Frage ob Einheitlichkeit automatisch als (gutes) Design erkannt wird. Und der Nachteil eines einheitlichen »Design« wäre doch erstmal kaum fehlende semantische Logik; um welche konkreten Beispiele geht es überhaupt?
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 06. 01. 2004, 21:42
Hallo Cyx,
wolltest Du nicht eher auf emus Posting antworten? So scheint es mir
jedenfalls. ;)
»» Hinsichtlich der Navigation ist ja Gleichförmigkeit i.d.R. auch vorteilhaft.
Das würde ich so unterschreiben.
»» Und der Nachteil eines einheitlichen »Design« wäre doch erstmal kaum
»» fehlende semantische Logik; um welche konkreten Beispiele geht es überhaupt?
Ein bestehendes Design _kann_ eine Seite in ein Konzept einsperren und so
eine andere Art von Auszeichnung erzwingen, die nicht unbedingt dem Inhalt
der Seite angemessen ist. Aber hey: Um konkrete Beispiele zu fordern, bist
Du hier im falschen Thread. ;-)
Tim
Die folgende Nachricht zum Thema stammt von: Cyx23, 07. 01. 2004, 13:26
Hallo Tim,
»» wolltest Du nicht eher auf emus Posting antworten? So scheint es mir
»» jedenfalls. ;)
nun, die Überlegungen zur CI beziehen sich schon auf dein "Wäre eine mögliche Rechtfertigung."
»» Ein bestehendes Design _kann_ eine Seite in ein Konzept einsperren und so
»» eine andere Art von Auszeichnung erzwingen, die nicht unbedingt dem Inhalt
Das Problem ist mir klar, aber da überschneiden sich m.E. sowieso Unzulänglichkeiten (Browser, HTML, CSS) mit der Frage der semantischen Bedeutung von Layout.
Dazu kann das Problem nicht nur als Problem der betr. Seiten oder deren einheitlicher Behandlung verstanden werden, sondern auch als vielleicht korrigierbarer Fehler des jeweiligen für alle Seiten angewandten Konzepts.
Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.
»» der Seite angemessen ist. Aber hey: Um konkrete Beispiele zu fordern, bist
»» Du hier im falschen Thread. ;-)
Da das Thema doch nicht rein abstrakt ist, steht einer Konkretisierung doch nicht so viel im Wege ?-)
Und für das Ausgangsposting des Thread bleibe ich bei dem konkreten Vorschlag sich Frames oder ggf. Iframes zu bedienen, um Interfrenzen zu vermeiden. Wär doch was nach dem XML-Hype Frames zu entdecken!
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: at, 07. 01. 2004, 13:34
Hallo.
»» Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.
Das "fast" bezeichnet dann wahrscheinlich alle Ausnahmen durch _gutes_ Design, welches solche Umstände ja berücksichtigt ;-)
MfG, at
Die folgende Nachricht zum Thema stammt von: Cyx23, 08. 01. 2004, 12:41
Hallo,
»» »» Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.
»»
»» Das "fast" bezeichnet dann wahrscheinlich alle Ausnahmen durch _gutes_ Design, welches solche Umstände ja berücksichtigt ;-)
wenn dann mit dem guten Design auch semantische Anforderungen beim HTML-Code verbunden sind, kann ja der übliche Navigationsblock wie schon im Thread geschehen betrachtet werden, aber es gibt ja auch Sonderfälle wie "Impressum".
Bei einer auch üblichen separaten Anordnung der Links "Home" und "Impressum" bietet es sich m.E. an beide in ein address-Tag zu setzen. Wäre es nun sinnvoll in einem Link-Block, z.B. als Liste, auch <adress> zu verwenden, und für wen abgesehen vom Autor macht sich solch eine Auszeichnung derzeit irgendwie bemerkbar?
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: at, 08. 01. 2004, 14:58
Hallo.
»» wenn dann mit dem guten Design auch semantische Anforderungen beim HTML-Code verbunden sind, kann ja der übliche Navigationsblock wie schon im Thread geschehen betrachtet werden, aber es gibt ja auch Sonderfälle wie "Impressum".
Das halte ich -- wie bereits erwähnt -- für zu kurz gegriffen, denn meine Gedankensprünge beim Betrachten einer Präsentation kann der Autor niemals zuverlässig vorhersagen, weswegen ich als Autor dem Nutzer prinzipiell den Umweg über etwa "Home" erspare. Stattdessen biete ich ihm eine möglichst vollständige Navigation innerhalb der Seite -- im Sinne des Hypertextes wäre hier eine Sitemap im <frame> angebracht, was ich aber ablehne --, um die meisten Anflüge von spontaner Wissbegier, Neugier etc. in die richtigen Kanäle zu leiten.
»» Bei einer auch üblichen separaten Anordnung der Links "Home" und "Impressum" bietet es sich m.E. an beide in ein address-Tag zu setzen. Wäre es nun sinnvoll in einem Link-Block, z.B. als Liste, auch <adress> zu verwenden, und für wen abgesehen vom Autor macht sich solch eine Auszeichnung derzeit irgendwie bemerkbar?
Inwieweit sich etwas bemerkbar macht, obliegt nicht HTML, sondern CSS, weswegen meine Antwort lautet: Natürlich macht es sich bemerkbar, wenn ich das will. Ich halte allerdings <a href...> für hinreichend kennzeichnend für eine URL. Hinzu kommt, dass ich <address> für Adressen verwende, die nicht mittels <a href...> erreichbar sind, und so zumindest eine Unterscheidbarkeit gewährleiste. Das einzige gemeinsame Auftreten von <address> und <a href...> sind bei mir Hausanschriften (<address>) mit einem integrierten Verweis (<a href...>) auf die Anfahrtskizze. Ein Klick beamt mich also nicht zur physischen Adresse, sondern zu einer weiteren HTTP-Ressource.
MfG, at
Die folgende Nachricht zum Thema stammt von: Cyx23, 08. 01. 2004, 15:56
Hallo,
»» Inwieweit sich etwas bemerkbar macht, obliegt nicht HTML, sondern CSS,
ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.
Das Impressum ist m.E. ein gutes Beispiel für die Interferenz verschiedener Hierarchien, u.U. auch "Home".
Der adress-Tag bietet womöglich eine semantische Zuordnung von Impressum oder Kontakt-e-mail, hat allerdings vmtl. nur begrenzt die Möglichkeit eingebundene Links als weniger zum eigentlichen Inhalt gehörig zu charakterisieren.
Grüsse,
Cyx23
Die folgende Nachricht zum Thema stammt von: at, 08. 01. 2004, 21:43
Hallo.
»» ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.
_Screen_reader? _News_reader und Programme wie http://www.apple.com/macosx/features/sherlock/ sind für mich Inbegriffe des semantischen Web -- aber vielleicht irre ich mich da auch.
»» Das Impressum ist m.E. ein gutes Beispiel für die Interferenz verschiedener Hierarchien, u.U. auch "Home".
»» Der adress-Tag bietet womöglich eine semantische Zuordnung von Impressum oder Kontakt-e-mail, hat allerdings vmtl. nur begrenzt die Möglichkeit eingebundene Links als weniger zum eigentlichen Inhalt gehörig zu charakterisieren.
Das <address>-Tag ist mir zu allgemein spezifiziert, als dass ich mir vorstellen könnte, mich in Bezug auf wichtige Dinge wie eine Kontakt-eMail-Adresse oder ein Impressum darauf zu verlassen. Aber im Zusammenhang mit dem semantischen Web messe ich den Meta-Angaben auch wieder eine größere Bedeutung bei, so dass wieder ganz andere Möglichkeiten zur Verfügung stehen.
MfG, at
Die folgende Nachricht zum Thema stammt von: Cyx23, 09. 01. 2004, 14:56
Hallo,
»» »» ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.
»»
»» _Screen_reader? _News_reader und Programme wie http://www.apple.com/macosx/features/sherlock/ sind für mich Inbegriffe des semantischen Web -- aber vielleicht irre ich mich da auch.
den Ansatz formulierte Berners-Lee als Ziel "Machine-Understandable information: Semantic Web" und "not only for human-human communication, but also that machines would be able to participate and help.".
Dann bemängelte er "that the structure of the data is not evident to a robot browsing the web" und führt aus dass es ihm nicht um bessere "artificial intelligence" sondern um " languages for expressing information in a machine processable form" geht.
Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich zuerst auf Screenreader oder Google wenn ich mal proprietäre Ansätze und Werbeideen weniger berücksichtige; der von dir genannte Sherlock ist allerdings interessant, Newsreader scheinen mir eher ein Sonderfall zu sein.
»» Aber im Zusammenhang mit dem semantischen Web messe ich den Meta-Angaben auch wieder eine größere Bedeutung bei, so dass wieder ganz andere Möglichkeiten zur Verfügung stehen.
Das war ja auch meine Frage bzw. d. Ausgangsproblem, dass Google als z.Zt. grösster potentieller Nutzniesser eines "semantic web" Meta-Angaben kaum nutzt, beim adress-Tag mag es ähnlich sein.
Immer noch soll ein Impressum-Link womöglich ohne Scrollen erreichbar sein, eine naheliegende Angabe im Head, Quelltext oder Link-tag sind auch hier zumindest hinsichtlich der Impressumspflicht nutzlos.
Und die eigentliche Bedeutung oder auch mal Unwichtigkeit des bzw. dieses Impressums ist wieder eine andere Geschichte.
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 09. 01. 2004, 17:10
Hallo Cyx,
»» Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich
»» zuerst auf Screenreader (..)
Was immer noch nicht erklärt, was Screenreader (als Synonym für Audiobrowser?)
mehr mit dem semantischen Web zu tun haben als die gewöhnten grafischen
Browser. Erklärst Du das nochmal, bitte?
Tim
Die folgende Nachricht zum Thema stammt von: Cyx23, 09. 01. 2004, 18:09
Hallo Tim,
»» »» Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich
»» »» zuerst auf Screenreader (..)
»»
»» Was immer noch nicht erklärt, was Screenreader (als Synonym für Audiobrowser?)
»» mehr mit dem semantischen Web zu tun haben als die gewöhnten grafischen
»» Browser. Erklärst Du das nochmal, bitte?
wenn ich entspr. den vorher genannten Zitaten weniger auf die Ablage von Datensätzen abziele, sondern die Kommunikation und die erwähnten teilhabenden und helfenden Maschinen betrachte, ist es doch naheliegend, so fehlt ja dem Screenreader genau der beim grafischen Browser durch Layout und CSS vorhandene Kontext, an spezielle Anforderungen wie lang-Attribute hatte ich weniger gedacht, aber die Forderung "Machine-Understandable information" per (HTM-)Sprache könnte sogar das abdecken.
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: Tim Tepaße, 09. 01. 2004, 18:47
Hallo Cax,
»» (..) so fehlt ja dem Screenreader genau der beim grafischen Browser durch
»» Layout und CSS vorhandene Kontext, an spezielle Anforderungen wie
»» lang-Attribute hatte ich weniger gedacht, aber die Forderung
»» "Machine-Understandable information" per (HTM-)Sprache könnte sogar das
»» abdecken.
Mhh. Das würde ich höchstens als Semantisches Web auf niedrigstem Niveau
durchgehen lassen. Schließlich ist die »machine-understandable information«,
die durch HTML abgedeckt wird noch auf sehr niedrigem Niveau, mehr kann
ein derzeitiger Screenreader nicht zu Verfügung haben.
Aber interessant, daß Du dem durch ein CSS-Layout gegebenen Kontext ein
soviel mehr an Information zugestehst. Hast Du dafür ein konkretes Beispiel,
an dem ich diese Vermutung nachvollziehen könnte? Ich meine hier konkret
eine HTML-Seite, in der die Variante der Darstellung mit Layout gegenüber
der Darstellung ohne Layout einen wirklichen informationellen Mehrwert hat.
Ich meine nicht Seiten, in denen der Autor sich nicht wirklich um angemessene
Auszeichnung bemüht hat bzw. sich nur auf Grafiken verlässt. Das ist dann
doch ein Unterschied, meine ich.
Mir würde da höchstens molilys Schachtelmodell einer HTML Dokumentenstruktur
auf dieser Seite einfallen: http://molily.de/dokumentmodelle.
(Runterscrollen bis Schachtelmodell, es gibt leider keine Anker.)
molily hat die Verschachtelung zwar als verschachtelte Liste ausgezeichnet,
die grafische Variante als Kästchen in Kästchen gibt jedoch ein kleines
bischen mehr an Information, meine ich. Hast Du vielleicht etwas adäquates?
Tim
Die folgende Nachricht zum Thema stammt von: Cyx23, 10. 01. 2004, 12:28
Hallo,
»» Aber interessant, daß Du dem durch ein CSS-Layout gegebenen Kontext ein
»» soviel mehr an Information zugestehst. Hast Du dafür ein konkretes Beispiel,
»» an dem ich diese Vermutung nachvollziehen könnte? Ich meine hier konkret
»» eine HTML-Seite, in der die Variante der Darstellung mit Layout gegenüber
»» der Darstellung ohne Layout einen wirklichen informationellen Mehrwert hat.
»» Ich meine nicht Seiten, in denen der Autor sich nicht wirklich um angemessene
»» Auszeichnung bemüht hat bzw. sich nur auf Grafiken verlässt. Das ist dann
»» doch ein Unterschied, meine ich.
nicht unbedingt. Wenn ein Autor die Unzulänglichkeiten und Begrenzheit
des Sprachumfangs, also auch den Punkt ab welchem Layout noch bedeutsamer
wird, besonders berücksichtigt und die Seite z.B. barrierefrei nachrüstet
bestätigt das ja den Informationscharakter von Layout.
Die möglichen Vorteile eines stimmigen reduzierten und vielleicht auch textbasierten
Layouts änderen daran nichts und sind eben keine Bestätigung dafür den verfügbaren
Leistungsumfang und Wortschatz immer weiter zu reduzieren.
Einfache Beispiele sind farbliche Differenzierungen, oder das Beispiel
(rechtliches) Impressum und seine oft fehlende inhaltliche Bedeutung trotz
prominenter Platzierung (oft ausserhalb d. Navigation, z.B. oben rechts).
»» molily hat die Verschachtelung zwar als verschachtelte Liste ausgezeichnet,
»» die grafische Variante als Kästchen in Kästchen gibt jedoch ein kleines
»» bischen mehr an Information, meine ich. Hast Du vielleicht etwas adäquates?
Ich bring da mal einige -wenn die betr. Seite barrierefrei sein soll teilweise
unpassende- Punkte an da molily vmtl. mitliest und es zum Thema passt.
Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,
und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.
In der Tabelle "Syntaxbestandteile und deren Bezeichnungen" ist dann
doch mal Farbe, aber da hätte es <strong> alleine m.E. besser getan, auch wenn
ich die Farbe grundätzlich als wohltuend empfand.
Gleichzeitig könnte die Farbe beim Schachtelmodell natürlich weitere Bedeutungen
oder Schwerpunkte entstehen lassen, so wäre eine Hervorhebung der Elemente im
Body interessant um den Bezug zur dargestellten Seite zu verdeutlichen, ansatzweise
geschieht das bereits durch die heller werdenden Grautöne.
Wäre solch eine Variante nun angemessen auszuzeichnen?
Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
Links angemessen auszuzeichnen?
Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
Abstand bzw. Leerraum zwichen zwei oben rechts und links
in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
und etwa in <adress> stehen könnten, angemessen auszeichnen?
Grüsse
Cyx23
Die folgende Nachricht zum Thema stammt von: at, 10. 01. 2004, 16:38
Hallo.
»» nicht unbedingt. Wenn ein Autor die Unzulänglichkeiten und Begrenzheit
»» des Sprachumfangs, also auch den Punkt ab welchem Layout noch bedeutsamer
»» wird, besonders berücksichtigt und die Seite z.B. barrierefrei nachrüstet
»» bestätigt das ja den Informationscharakter von Layout.
»» Die möglichen Vorteile eines stimmigen reduzierten und vielleicht auch textbasierten
»» Layouts änderen daran nichts und sind eben keine Bestätigung dafür den verfügbaren
»» Leistungsumfang und Wortschatz immer weiter zu reduzieren.
Ich wollte gerade protestieren und auf bereits geführte Diskussionen zu diesem Thema hinweisen, ...
»» Einfache Beispiele sind farbliche Differenzierungen, oder das Beispiel
»» (rechtliches) Impressum und seine oft fehlende inhaltliche Bedeutung trotz
»» prominenter Platzierung (oft ausserhalb d. Navigation, z.B. oben rechts).
... als du mich daran erinnert hast, wie weit du den Begriff "Layout" fasst :-)
MfG, at
Die folgende Nachricht zum Thema stammt von: molily, 10. 01. 2004, 21:23
»» Ich bring da mal einige -wenn die betr. Seite barrierefrei sein soll teilweise unpassende- Punkte an da molily vmtl. mitliest und es zum Thema passt.
Nein, ich lese nicht mit. Aber es gibt ja Referrer. Also demnächst eher als E-Mail schicken, wenn die Kommentare ankommen sollen.
»» Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,
Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.
»» und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.
Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.
»» In der Tabelle "Syntaxbestandteile und deren Bezeichnungen" ist dann doch mal Farbe, aber da hätte es <strong> alleine m.E. besser getan, auch wenn ich die Farbe grundätzlich als wohltuend empfand.
Alleine durch die strong-Hervorhebung war in meinen Tests nicht so gut erkennbar, welcher Codeteil gemeint war. Das gilt auch jetzt noch, Netscape 4 wendet die Farben nämlich nicht an. Außerdem wollte ich an die Farbgebung des Diagramms darüber anknüpfen (vielleicht siehst du nur den Alternativinhalt... muss ich mal anders umsetzen, momentan zeigt bspw. MSIE gar nichts an).
»» Gleichzeitig könnte die Farbe beim Schachtelmodell natürlich weitere Bedeutungen oder Schwerpunkte entstehen lassen,
Inwiefern?
»» so wäre eine Hervorhebung der Elemente im Body interessant um den Bezug zur dargestellten Seite zu verdeutlichen, ansatzweise geschieht das bereits durch die heller werdenden Grautöne.
Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? Es geht um die Untersuchung der Elementhierarchie, also um die Frage der richtigen Einordnung von Informationen (passt dieses und jenes Element in die Schachtel/Kategorie XYZ, welche Gemeinsamkeiten hat es mit den anderen Elementen in der Schachtel, ergibt die Sequenz Sinn, ...). Das gilt nicht nur oder im speziellen für die Elemente im body. In diesem Thread kam z.B. die Frage auf, ob so etwas wie eine sogenannte Primärnavigation wirklich in den Körper gehört oder ob es sich bei rel="chapter"-Links eher um »Kopfdaten« und Meta-Verknüpfungen handelt, die eher in die Kiste head gehören. Das Verfahren, auf das ich hinaus will, sollte auch darauf eine Antwort geben können (von praktischen Umständen einmal abgesehen - die Methode hat ja auch bewusst einen begrenzten Anwendungsbereich und soll auch nicht alleinig seelig machen).
»» Wäre solch eine Variante nun angemessen auszuzeichnen?
»» Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
»» Links angemessen auszuzeichnen?
»» Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
»» Abstand bzw. Leerraum zwichen zwei oben rechts und links
»» in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
»» und etwa in <adress> stehen könnten, angemessen auszeichnen?
Ähm - wie bitte?
Die folgende Nachricht zum Thema stammt von: Cyx23, 11. 01. 2004, 00:40
»» »» Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,
»»
»» Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.
auch wenn ich die genannten Punkte begründen kann sollte mein Posting keine ausgefeilte Kritik mit besseren Lösungen sein, aber mal schauen.
Die Hierarchien so per Graustufen darzustellen wäre mir nicht so wichtig da ich die räumliche Aussage der Rahmen oder den Schachtelcharakter wichtiger oder ohne Graustufen vielleicht deutlicher fände.
»» »» und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.
»»
»» Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.
Die Probleme und Interferenzen möglicher Interpretationen und Bedeutungen könnten natürlich durch das Wissen um Syntax-Highlighting noch grösser werden, aber ich meinte besonders eine angenehmere schnellere Erfassung, wenn natürlich solch ein Komfort -sofern er wirklich möglich ist- die Aussage verändert wird es schwierig.
»» Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? Es geht um die Untersuchung der Elementhierarchie, also um die Frage der richtigen Einordnung von Informationen (passt dieses und jenes Element in die Schachtel/Kategorie XYZ, welche Gemeinsamkeiten hat es mit den anderen Elementen in der Schachtel, ergibt die Sequenz Sinn, ...). Das gilt nicht nur oder im speziellen für die Elemente im body. In diesem Thread kam z.B. die Frage auf, ob so etwas wie eine sogenannte Primärnavigation wirklich in den Körper gehört oder ob es sich bei rel="chapter"-Links eher um »Kopfdaten« und Meta-Verknüpfungen handelt, die eher in die Kiste head gehören. Das Verfahren, auf das ich hinaus will, sollte auch darauf eine Antwort geben können (von praktischen Umständen einmal abgesehen - die Methode hat ja auch bewusst einen begrenzten Anwendungsbereich und soll auch nicht alleinig seelig machen).
Es ist vielleicht auch besser in einer Darstellung nicht zuviele Themen zu vermengen , aber »Der Bezug zur dargestellten Seite« bzw. eine Abgrenzung des Body könnte vielleicht die Anschaulichkeit etwas verbessern, und eine farbliche Gruppierung Body vs Head würde m.E. einfach die Wahrnehmung vereinfachen, ich hab es allerdings nicht getestet.
»» »» Wäre solch eine Variante nun angemessen auszuzeichnen?
»» »» Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
»» »» Links angemessen auszuzeichnen?
»» »» Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
»» »» Abstand bzw. Leerraum zwichen zwei oben rechts und links
»» »» in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
»» »» und etwa in <adress> stehen könnten, angemessen auszeichnen?
»»
»» Ähm - wie bitte?
Meine angenommene Beispielseite sieht ganz oben so aus ([link]):
[www.muster.de]/[beispiel]/diesedatei.html [impressum]
also schamtisch auch so
[w..e]/[b..l]/di..i.html - L E E R R A U M - [i..m]
und wenn das Impressum inhaltlich weniger wichtig ist, erhält der betr. a-tag [impressum] z.B. ein color:silver.
Wie würde nun diese Farbgebung bzw. die etwas geringer Auffälligkeit und Wichtigkeit für ein "sematic web" dargestellt werden, wie der beabsichtigte und bei den meisten üblichen Auflösungen vorhandene Leerraum, der vielleicht mit <div><span><a...></span><span><a..>impressum</a></span></div> nicht deutlich wird, aber natürlich kein eigenes Element erhalten soll.
Die folgende Nachricht zum Thema stammt von: molily, 11. 01. 2004, 05:40
»» »» »» Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,
»» »»
»» »» Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.
»»
»» auch wenn ich die genannten Punkte begründen kann sollte mein Posting keine ausgefeilte Kritik mit besseren Lösungen sein, aber mal schauen.
»» Die Hierarchien so per Graustufen darzustellen wäre mir nicht so wichtig da ich die räumliche Aussage der Rahmen oder den Schachtelcharakter wichtiger oder ohne Graustufen vielleicht deutlicher fände.
Was ist die »räumliche Aussage der Rahmen«? Die Rechtecke enthalten einander, da müsste ich im Prinzip weder an Rahmen noch an Hintergrundfarbe viel ändern, das würde auch so deutlich. Ich will ja gerade den Schachtelcharakter hervorheben, inwiefern ist das ohne Graustufen deutlicher und wie könnte ich den sonst betonen?
Während der Rahmen den Raum umgrenzt und die Kanten bietet, füllt die Hintergrundfarbe den entstehenden Raum als begrenzte Fläche aus, daher würde ich unterschiedliche Rahmenfarben nicht als Indikator der Ebenentiefe auffassen, sondern als Typangabe eines Elements. Aber diese zu kategorisieren, etwa nach Namen oder Bedeutung, ist auf dieser Ebene der Analyse zumindest nicht das, was ich mit der grafischen Darstellung aufzeigen wollte.
»» »» »» und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.
»» »»
»» »» Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.
»»
»» Die Probleme und Interferenzen möglicher Interpretationen und Bedeutungen könnten natürlich durch das Wissen um Syntax-Highlighting noch grösser werden, aber ich meinte besonders eine angenehmere schnellere Erfassung, wenn natürlich solch ein Komfort -sofern er wirklich möglich ist- die Aussage verändert wird es schwierig.
Ja gut, uninteressant finde ich solche Möglichkeiten und solchen Komfort ja nicht, vielleicht bündle ich verschiedene Darstellungen irgendwann zu einer. Nach welchem Schema könnten die Tags denn eventuell gefärbt sein? Meintest du generell eine Unterscheidung zwischen Markup und natürlicher Sprache (Tags in einer Farbe, normaler Text - das sind ja immer Textknoten - in einer Farbe)? Das könnte ich dort sogar machen, weil Textknoten im Schachtelmodell ebenfalls eine andere Farbe habe (eigentlich deshalb, weil sie selbst keine Schachteln sind, sondern das, was es einzusortieren gilt).
»» »» Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? [...]
»»
»» Es ist vielleicht auch besser in einer Darstellung nicht zuviele Themen zu vermengen , aber »Der Bezug zur dargestellten Seite« bzw. eine Abgrenzung des Body könnte vielleicht die Anschaulichkeit etwas verbessern, und eine farbliche Gruppierung Body vs Head würde m.E. einfach die Wahrnehmung vereinfachen, ich hab es allerdings nicht getestet.
Möglich, aber ich sehe nicht, wie diese Dimension im speziellen Kontext meines Artikels relevant ist. Sicherlich sind head und body genauso wie title exponierte »Schachteln«, dieser grundlegende Aufbau jedes Dokuments prägt alle weiteren Entscheidungen, aber diesen Aufbau will ich an dieser Stelle nicht als solchen veranschaulichen noch finde ich es wichtig, ihn dort anzusprechen. Dann nehme ich mich dieser und anderer Markupstrukturen lieber noch einmal gesondert an, indem ich sie einzeln betrachte und bspw. die grundlegende Unterscheidung zwischen head und body behandle.
Was ich mir denken kann, ist eine Abtrennung in Form von mehr Leerraum um head und body... aber auf diese stärkeren Einschnitte bzw. Zusammenhänge, die nicht bei der gleichmacherischen Darstellung zu Tage treten bzw. nicht explizit in Form von Schachteln auftreten, wollte ich sowieso an anderer Stelle noch eingehen.
»» »» »» Kann ich die durch eine bestimmte F
(HTML)