Danke, dass du dir die Mühe machst!
Diese Ausgabe habe ich auch, wenn ich nur den normalen Inhalt benutze. Aber sobald ich das Plugin nutze (bzw. überhaupt irgendwas "exotisches", habe da ja verschiedenste Variationen ausprobiert) werden diese <a>-Tags davor, dahinter und dazwischen gepackt. Deshalb meinte ich ja, dass am CSS es nicht liegen dürfte - da es ja im Prinzip funktioniert. Erst der Player (egal ob fe_mp3player, audioplayer, 1pixelout, etc...) bringt da Unruhe rein.
<a ...> | </a> soll um den gesamten Spalteninhalt gewrapt werden. Und das wird es ja auch, wenn in der Spalte nur Standardinhalt steht.
Steht das Plugin drin wird so gewrapt
<a ...> </a>
<div csc-content>
<a ...><div csc-header> </div></a>
<div csc-imagetext> </div>
<a ...> </a>
</div>
<a ...> <a>
Also total "willkürlich" eingeschobene <a ...> </a> ... und die Spalte wird gewrapt wie
<a ...> </a> | <a ...> </a>
Ich verzweilfel bald echt daran, so eine Sch****
Schade. Offensichtlich kann ich Dir nicht weiter helfen. 😢
Aber mal eine Gedanke dazu. Eine einzige Inhaltsspalte (Normal) verwenden und um jeden Content-Element Deine Links setzen. Kommt auf das Gleiche raus. Oder?
.
Ich vermute da liegt das Problem eher am unvermögen der Browser -> ein a Tag umschließt etwas was der Browser nicht von a umschlossen haben will -> Fehlerkorrektur setzt ein und beendet das a Tag vor dem Bösen Element und öffnet es dahinter wieder. Ergebnis ist das von dir beschriebene. HTML5 war zwar eine gute Idee, das laut Spezifikation auch funktionieren sollte, aber das heißt ja nicht, dass auch die Browser das so halten... Ich vermute da wird ja ein object oder embed generiert und da mag dann offensichtlich FF kein a drum. Ich würde dir empfehlen um das a noch ein div zu wrappen und darin die Styles zu setzen. Dann ist es ja im Grunde egal ob der Browser die a Tags auseinander nimmt.
Danke für dein Bemühen!
Allen Content in eine Spalte und um jeden dann ein <a> würde denke ich das selbe darstellen, da die Spalten ja auch nur von den <a>s getrennt werden, und will ich auch nicht, da man schon pro Spalte mehrere Contentelemente untereinander packen können soll.
Werde das mal mit den Divs probieren, vlt kann ich die <a>s ja komplett rauspacken, aber ich glaube die sind unverzichtbar für die Scrollfunktion mit den JS-Scripts...
Würd das Fenster weiter aufgehen wär der Rechner schon längst hier aus dem 5. Stock geflogen :-) erstmal eine Rauchen gehen...
Kitsunet schrieb
Ich vermute da liegt das Problem eher am unvermögen der Browser -> ein a Tag umschließt etwas was der Browser nicht von a umschlossen haben will -> Fehlerkorrektur setzt ein und beendet das a Tag vor dem Bösen Element und öffnet es dahinter wieder.
Dass könnte passieren, wenn schließender oder öffnender Tag eines Elements fehlen oder an der falschen Stelle stehen (falsch verschachtelt). Oder der Browser kennt das Element nicht.
Ich denke, das ist hier nicht der Fall.
Kitsunet schriebIch würde dir empfehlen um das a noch ein div zu wrappen und darin die Styles zu setzen. Dann ist es ja im Grunde egal ob der Browser die a Tags auseinander nimmt.
Um die CSS-Formatierung alleine geht es nicht, wenn ich das richtig verstehe. Jeder Link soll halt eine Spalte beinhalten.
Ich hoffe, die Sache ist viel einfacher, als sie im Moment zu sein scheint. Ich kann gerade keine Zeile Code mehr sehen – nach rund 18 Stunden vor dem Bildschirm. 8-)
Viel Erfolg
.
plxkillme schrieb
Allen Content in eine Spalte und um jeden dann ein <a> würde denke ich das selbe darstellen, da die Spalten ja auch nur von den <a>s getrennt werden, und will ich auch nicht, da man schon pro Spalte mehrere Contentelemente untereinander packen können soll.
Es war auch nicht als Lösung Deines Problems gedacht, sondern als einfachere Handhabung.
Allerdings sind mir die Argumente eingefallen, die Du beschrieben hast, glei nach dem ich den Beitrag gepostet habe. Vergiss also meine „Gedanke“. 😃
Lösung:
Ein per <embed> eingebundenes Element darf nicht mit <a> </a> als Link gesetzt werden. (Danke kitsunet für den Hinweis!)
Daher ist ein Wrap um ein <embed> in der Form <a> | </a> nicht möglich.
Da aber die <a>-Tags ja nicht als Link gedacht waren, sondern nur als (vorausgesetztes) Hilfsmittel für die Scrollfunktion, hat mit ein Wrap in Form <div><a> </a> | </div> geholfen.
die <a>-Tags ermöglichen das Scrollen mit den Javascripts und die Divs halten das ganze schön nebeneinander (natürlich mit float).
Danke euch beiden!
Kaum macht man's richtig, schon funktioniert's!
Lösung #2:
Weg mit den <a>-Tags, ersetzen durch <div>,
href="javascript: void" wird zu onlick="javascript: void",
Die CSS-Klassen vom <a> ins <div> packen
Die JS-Scripts anpassen und fertig...
Funktionalität wie vorher erhalten, mit Scrollen bei klick auf ganzes Element, Fade-in und Fade-out, ...
Eine kleine Korrektur auf die Schnelle:
Kitsunet schrieb oben, dass die fehlerhafte Darstellung vermutlich am „unvermögen der Browser“ liegt. Dies hatte ich widersprochen. Zu Unrecht, wie ich gerade feststellen müsste:
Bin gerade dabei Definitionslisten in Links zu setzen.
Zumindest Firefox, bzw. Firebug interpretiert den Code falsch und setzt die Links vor den Definitionslisten. Und zwar unabhängig davon, ob ich die Definitionslisten in einem extra DIV oder direkt in den Links setze.
In Opera und Chrome dagegen – alles bestens. Weitere Browser habe ich nicht getestet.
Hallo,
ich würde nicht sagen, dass es am Unvermögen der Browser liegt. In HTML 4 ist nicht genau definiert, welche Elemente ein a-Tag umschließen darf, allerdings gehen alle Beispiele auf w3.org von reinen Inline-Elementen aus. Wie üblich in solchen Fällen interpretieren das die Browserhersteller dann unterschiedlich. Rein gefühlsmäßig würde ich sagen, HTML4 beschränkt den Inhalt von a auf Text und Bild.
In XHTML sind innerhalb von a m. W. auch nur Inline-Elemente erlaubt, mit Ausnahme von Links (Links dürfen nicht geschachtelt werden. Das wären also wieder Text + Bilder.
In HTML5 ist es dann exakt definiert: der a-Tag kann sog. phrasing-Content und ineractive-Content umschließen. http://www.w3.org.
Das umfasst bereits eine Menge, auch embed, aber keine Listen und keine div.
Also hat wohl Firefox Recht.
Peter, TYPO3 @ lisardo (Augsburg)
- Nachtrag: sehe gerade, dass es in HTML4 schon definiert ist: http://www.w3.org/: eindeutig inline-Kontext. Dann gilt das auch für XHTML.
Erstmal freut es mich, dass du eine Lösung zu deinem Problem gefunden hast.
Bin technisch irgendwo im zweiten Drittel der Beiträge ausgestiegen.
Was ich aber ja auch eigentlich schreiben wollte...
Finde die Seite hat ein interessantes und gewagtes Design usw. Respekt für den Mut und hoffe die Seite hat den gewünschten Erfolg.