Und display:inline-block? Laut HTML-Standard ist etwas, wie
also nicht erlaubt, aber
schon. An dieser Stelle finde ich HTML nicht sehr konsistent. Gut, als man entschieden hat, dass Inline-Elemente keine Block-Elemente enthalten können, hat man wahrscheinlich nicht daran gedacht, dass es mal etwas, wie inline-block geben wird...

Sicher. Aber wenn man von der Bedeutung der Elemente mal absieht, könnte man mit genügend CSS jede HTML 4 basierte Seite allein aus DIVs, IFrames, dem Title und ein paar Input-Geschichten aufbauen. Alles andere, von Listen bis Tabellen, kann man irgendwie umbauen, bis es faktisch exakt das gleiche ist.

Zumindest die Rendering-Engine des Browsers beachtet, so habe ich den Eindruck, das eigentliche HTML-Tag höchstens noch, um zu entscheiden, welche standard-css-Einstellungen für das Element gesetzt werden sollen.

Da man inzwischen auch den Text in css auslagern kann, ist es technisch also durchaus denkbar, eine Seite zu schreiben, in der die HTML-Elemente nur noch die Verkapselung beschreiben. Sinnvoll ist das natürlich nicht.

Wieso?
Ich denke du vermischt gedanklich hier mehrere Dinge.

Einmal gibt es eine Syntax, daraus entsteht die Validität. Diese bestimmt welche Elemente, wann erlaubt sind.

Völlig unabhängig davon, sollten HTML Elemente semantisch verwendet werden, also anhand ihrer Bedeutung. Das ist aber nur eine "Gebrauchsanleitung" und ob du das machst oder nicht, ist im Prinzip deine Entscheidung. Aber wenn es um Semantik geht, ist dein zweites Beispiel fragwürdig, da zwei ineinander verschachtelte bedeutungslose Elemente keinen Sinn ergeben.

Trotzdem wirst du so ein Konstrukt öfters finden, wegen dem dritten Aspekt: die Gestaltung. Diese ist völlig unabhängig von Semantik und Validität. Und daher kannst du das CSS theoretisch wie in deinem zweitem Beispiel benutzen, solange es nicht der Syntax von CSS widerspricht, hast du hier freie Hand.

Im Prinzip musst du einfach versuchen, gedanklich das HTML von der Gestaltung zu trennen. Ein HTML Blockelement muss nicht (durch CSS) als Blockelement gestaltet sein

Exakt. Aber du sagst es selber "wenn man von der Bedeutung absieht"

Ja genau, die Darstellung regelt einzig und allein das CSS. Und das HTML ist dazu da, deinen Inhalt nach seiner Bedeutung zu beschreiben. Du kannst darauf verzichten, nimmst dann aber in kauf, dass dein Dokument ohne die Gestaltung durch das CSS kaum lesbar ist und automatisiert z.b. durch Suchmaschinen wird der Inhalt nicht mehr so gut auswertbar sein.

hmm, das versucht man dir dauernd zu erklären: Elemente sind HTML (Semantik, Aussage, Bedeutung), inline-block ist CSS (Styling, Optik).

Der Unterschied ist mir schon klar. Ich wollte ja nur anmerken, dass ich es semantisch sinnvoller finde, HTML-Block-Elemente auch als solche zu verwenden. Ich meine, wenn jemand den Code liest und DIV sieht, rechnet er wohl nicht damit, dass irgend ein Stylesheet daraus ein als inline angezeigtes Element gemacht hat...

Aber ich glaube, das ist jetzt irgendwie off-topic.

Es macht überhaupt nicht den Eindruck, dass dir etwas klar ist.

Du hast es noch immer nicht begriffen. Du kannst ein Blockelement gar nicht als etwas anderes verwenden. Ein Blockelement bleibt immer ein Blockelement in HTML.

Das ist Quatsch. Es ist völlig normal, die Default-Darstellung von Elementen so ändern, wie man es fürs Layout haben möchte. Genau dafür ist CSS da.
Mit Semantik hat das überhaupt gar nichts zu tun.

__________________
Corina Rudel

Online-Einsteigerkurs HTML/CSS | Buch: Fortgeschrittene CSS-Techniken

Doch, ich habe es verstanden.

Wenn man schreibt <DIV style="display : inline; "> dann ist und bleibt das ganze ein DIV und DIV ist ein Blockelement, aber mit display:inline verwendet man es eben nicht als solches. Und genau das kann verwirren, finde ich.

Es ging ja ursprünglich nur darum, dass BaTam mit der float-Eigenschaft diverse Elemente als Blockelemente dargestellt hat, um diese in einer Reihe aufzulisten. Und so man die Möglichkeit hat, auch den HTML-Content zu ändern, würde ich lieber einheitliche DIV-Elemente benutzen, die in einer Reihe aufgelistet sind, und die dann alles andere enthalten.

Wenn man sich mal anschaut, wie verschwenderisch automatisch generierter Code HTML-Elemente einsetzt, um irgendetwas zu kapseln, ist es doch moderat, für die Positionierung hier eine Reihe aus DIVs zu verwenden. Dann weiß man: Die DIVs sind für die Position da und die anderen Elemente haben erst mal ihre normalen Eigenschaften. Denn wenn BaTam jetzt ein JavaScript schreibt, dann kann er mit den DIVs unkompliziert eine allgemeine Struktur erzeugen und das Script später für andere SlideNavs wiederverwenden, auch, wenn diese wieder ganz neue Elemente beinhalten...

Das ist falsch. Man kann ein Blockelement nicht als inline-Element verwenden. Man kann es nur so darstellen.
Das ist der riesige Unterschied, den man hier schon seitenweise versucht, dir klarzumachen!

Wenn es darum geht, etwas aufzulisten, dann verwendet man eine Liste! Wie diese Liste dann dargestellt wird legt man im CSS fest.

Das Markup, das der OP ursprünglich gepostet hat, sieht für den Zweck sehr sinnvoll aus: Eine Liste von Elementen; zwei Buttons für die Bedienung per JavaScript, das ganze mit einem Div gruppiert. Die Elemente werden also genau für das eingesetzt, wofür sie vorgesehen sind. Alles richtig gemacht.
Völliger Unsinn wäre es, dieses sinnvolle Markup derart kaputtzumachen, wie du es vorschlägst.
Bitte versteh das doch endlich.

Was explanator ursprünglich anmerkte bezog sich lediglich auf die gleichzeitige Verwendung von display:inline und float bei ein und demselben Element -- also auf CSS. (Dass das nicht immer wirkungslos ist und was die wahrscheinliche Herkunft dieser Kombination ist, habe ich bereits erklärt.)
Leider hat der Satz "Wenn man ein Element floatet wird es zu einem Blockelement." zu eben dem Missverständnis geführt, das ich hier die ganze Zeit versuche, auszuräumen: Der OP dachte, er müsse etwas an seinem HTML ändern. Nein, das muss und sollte er nicht. Das HTML ist völlig in Ordnung und es ist auch völlig in Ordnung ein button-Element zu floaten!

Nein, so sollte man eben nicht vorgehen. Man sollte seinen Inhalt immer zuerst mit sinnvollem HTML auszeichnen -- dabei ist egal, wie später die Gestaltung aussehen soll. Der Inhalt entscheidet darüber, welche HTML-Elemente sinnvoll sind. Div-Elemente braucht man, um Gruppen von Elementen zusammenzufassen, nicht um zu "positionieren". Positionieren kann man nur mit CSS und das mit jedem Element.

Wenn man eine Gestaltung modular verwendbar halten will, dann vergibt man Klassen und verwendet im Stylesheet nur Klassenselektoren, keine Typselektoren. Dann ist es egal, ob man einmal ein <ul class="mymodule"> hat oder <article class="mymodule"> oder <div class="mymodule">. .mymodule { color:red} wirkt immer.

__________________
Corina Rudel

Online-Einsteigerkurs HTML/CSS | Buch: Fortgeschrittene CSS-Techniken

Zusammenfassend:"Block Element" ist keine Semantik. Das Block bezieht sich nur auf die Darstellung.

Ist "verwenden" jetzt ein geschützter Fachbegriff von HTML? Ich meine SPAN und DIV verwendet man hauptsächlich, um die Darstellung von etwas anzupassen und wenn man ein DIV als inline darstellt, verwendet man es folglich auch als inline. Das sind doch nur Wortklaubereien.

Ich habe mal in meinem Code aus Post #15 LI statt DIV verwendet:
Das erzeugt jedenfalls heftige Fehldarstellungen. DIV ist hier das allgemeinere Element. LI ist für mich eine Liste, im Sinne eines Inhaltsverzeichnisses oder einer Aufzählung. Aber eine SlideShow? Ein naturelles HTML-Element hierfür gibt es nicht, deswegen benötigt man ja diverse StyleSheets, um eine SlideShow darzustellen. Und bloß, weil es sich dabei um eine Art Liste handelt, LI zu verwenden und mit CSS herunzuformatieren, bis es irgendwie wieder stimmt... Das will mir einfach nicht gefallen.

Des weiteren verwenden viele, gerade für Elemente, wie LI, globale Stylesheets, die dann mit der SlideShow kollidieren können.

Mit einheitlichen DIVs könnte BaTam zum Beispiel eine JavaScript-Klasse schreiben, deren Konstruktor eine Beschreibung, wie "Receives a DIV element, that contains the slide DIV-blocks" genügte. Aber versuch' mal jemand zu erklären, dass die slide blocks alle möglichen Elemente sein können, aber dann doch wieder nicht alle.

Ich programmiere zwar erst seit ~5 Jahren, aber gerade aus der Anfangszeit habe ich etliche Codes, die einfach nicht allgemein genug gehalten sind und die ich jetzt wegwerfen kann.

Ich finde, die Darstellung sollte auch einer Semantik unterliegen. Jedenfalls ganz grob. Man kann mit CSS viel Unsinn anstellen...

Nein, es ist fürs Verständnis und die Kommunikation ein entscheidender Unterschied. Das merkst du doch in diesem Thread. Der einfache Satz "Wenn man ein Element floatet wird es zu einem Blockelement." hat zu einem völlig ausufernden Thread geführt. Eigentlich ging es nur darum, dass "display:inline" wirkungslos ist.

Die Fehldarstellunegn, die ich sehen kann, liegen

1. am Quirksmodus (völlig ungeeignet, wenn man etwas testen will!)
2. dem Typselektor in deinem Stylesheet (div.slideNav wirkt nicht bei einem ul-Element!)
3. den default-Styles der Listen.

Das mit ein paar Zeilen CSS zu lösen ist überhaupt kein Problem. Alles kein Grund, semantikfreies Markup zu verwenden.


Man könnte auch "Recieves an element with class "mymodule" that contains elements with class "mymodule-items" verwenden.
Und schon ist es egal, ob man bedeutungslose Divs oder semantisch sinnvolle Listenelemente verwendet.

Was du hier schreibst ist die Sichtweise eine Programmierers, der rein darauf bedacht ist, den Code für seine Zwecke leicht verarbeitbar zu halten.
Deshalb brauchen Projekte auch Spezialisten fürs Frontend, die darauf achten, dass HTML sinnvoll eingesetzt wird. Es gibt Nutzer, die sind darauf angewiesen, dass man ihnen sinnvolles HTML liefert. Nutzer von Screenreadern z.B.
Wenn du ein iOS oder OSX-Gerät hast, kannst du VoiceOver einschalten. Wenn du mal eine zeitlang versuchst, ohne hinzuschauen dich damit durchs Web zu bewegen, ändert sich deine Sichtweise auf die sinnvolle Verwendung von HTML-Elementen, glaub mir.

Ja, man kann mit CSS die Nutzbarkeit einer Website komplett zerstören. Aber das hat mit Semantik nichts zu tun! Semantik = Bedeutung kann nur das HTML haben!!einself!
Bitte, bitte versuch das zu verstehen. Semantik und CSS haben nichts miteinander zu tun.

__________________
Corina Rudel

Online-Einsteigerkurs HTML/CSS | Buch: Fortgeschrittene CSS-Techniken