Sinn ist zwar fraglich, aber wird hier des öfteren gefordert:
tt_content.stdWrap.innerWrap.cObject >
tt_content.stdWrap.innerWrap2 >
tt_content.dataWrap >
tt_content.prepend >
tt_content.textpic.20.text.10.10.stdWrap.dataWrap >
tt_content.image.20.imageStdWrap.dataWrap >
tt_content.image.20.imageStdWrapNoWidth.wrap >
tt_content.image.20.imageColumnStdWrap.dataWrap >
tt_content.image.20.layout.default.value = ###IMAGES######TEXT###
tt_content.image.20.layout.1.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.2.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.8.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.9.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.10.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.17.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.18.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.25.value < tt_content.image.20.layout.default.value
tt_content.image.20.layout.26.value < tt_content.image.20.layout.default.value
tt_content.image.20.rendering.dl.imageRowStdWrap.dataWrap >
tt_content.image.20.rendering.dl.oneImageStdWrap.dataWrap >
tt_content.image.20.rendering.dl.imgTagStdWrap.wrap >
tt_content.image.20.rendering.dl.editIconsStdWrap.wrap >
tt_content.image.20.rendering.dl.caption.wrap >
tt_content.textpic.20.text.10.10.stdWrap.dataWrap >
tt_content.textpic.20.text.wrap >
Was soll an dem Sinn den bitte fraglich sein? Ich jedenfalls hab hier gerade genau die Lösung von vielen Problemen gefunden, die der von Typo3 um Bilder herum gekleisterte Code immer wieder verursacht.
Wenn du mir jetzt noch erklärst, wie man Typo daran hindert, um in den Content eingebundene Plugins keinen Container zu wrappen, oder, wie man da die ellenlangen Class- und Id-Attribute raus schmeisst, darfst du dir virtuell auf die Schulter geklopft fühlen...
j4k3 schrieb
Was soll an dem Sinn den bitte fraglich sein?
Genau dieser ellenlange Code stört keine Sau aber ist ideal um kleinste Einstellungen über CSS vorzunehmen. Wenn du also Probleme hast, dann kannst du diese mit 99 prozentiger Sicherheit über CSS ausbügeln ohne den Code zu verändern.
Nachtrag: Außerdem musst du denn den Bild/Text Fluss selber zusammenbasteln
Um eine Extension (nicht TYPO3) daran zu hindern die baseClass zu setzen musst du schon das jeweilige PHP-Script bearbeiten.
Das hier sorgt z.B. für das Einbinden des der BaseClass:
return $this->pi_wrapInBaseClass($this->content);
Durch
return ($this->content);
Wird das dann verhindert
Allerdings kannst du dadurch auch schon wieder mit dem CSS der Extension Probleme bekommen, da oftmalls Class-namen auf der baseClass beruhen.
einpraegsam.net schrieb
j4k3 schrieb
Was soll an dem Sinn den bitte fraglich sein?
Genau dieser ellenlange Code stört keine Sau (…)
Aber hallo! Wer auch nur ein bisschen Sinn für Site Performance an den Tag legt, der wirft den ganzen generierten Codemüll sofort weg. Die Ausgabe steuer ich lieber selber, da weiß ich, dass mir wenigstens keine der genierten Klassen dazwischenfunkt.
Wenn eine Extension auf die Typo3-„Standards“ (haha?) basiert, dann sollte sich der Extensionschreiber nochmal Gedanken machen.
Man kann das sogar noch erweitern, um einiges. So zum Beispiel die völlig überflüssige Klasse "bodytext" im p-Tag oder die Klasse in den Überschriften. Und den div um die Hx (wozu zum Geier braucht man das?!)
lib {
parseFunc_RTE {
nonTypoTagStdWrap.encapsLines {
### entfernt "class=bodytext" aus p-Tags
addAttributes.P.class =
}
}
stdheader {
### entfernt div-Tag um Headlines
stdWrap.dataWrap = |
### entfernt "csc-firstHeader" aus Hx-Tags
10.1.fontTag = <h1>|</h1>
10.2.fontTag = <h2>|</h2>
10.3.fontTag = <h3>|</h3>
10.4.fontTag = <h4>|</h4>
10.5.fontTag = <h5>|</h5>
10.6.fontTag = <h6>|</h6>
}
}
Der Witz ist ja gerade, dass dieser Klassenwahn komplett den Sinn von CSS nicht wiedergibt.
Durch diese Entschlackung kann man reichlich kB sparen und das ist das A und O beim Thema Optimierung.
nur kurz mein Statement: Natürlich macht das Sinn wenn man ein paar Klassen weniger hat, aber die paar Klassen wegzugeben, das ist bei mir der letzte Schritt wie ich optimiere, da gibts ganz wesentlichere Schrauben
lg georg
Sicher Georg, das definitiv. Aber ich bin der Meinung, dass man den Output für’s Frontend selber steuern sollte (klar, wenn man’s kann) und jedes überflüssige Byte sparen.
Schlanker, sauberer Code, das ist was hübsches. 😃
datenkind schrieb
Schlanker, sauberer Code, das ist was hübsches. 😃
Darüber lässt sich sicher streiten, aber ich behaupte mal, dass deine Seiten auch nicht perfomanter sind, hier aber sehr viel mehr Arbeit drin steckt (gar nicht an Skalierbarkeit zu denken) - dessen bin ich mir sogar sicher.
Aber schön ist jedenfalls das mit TYPO3 alles machbar ist.
Das Thema können wir ja mal im Off-Top Bereich diskutieren. Ich mache diesen Thread mal zu, denn hier geht es um die Machbarkeit und nicht um den Sinn.