[holygrail 1.3.0] Das Holy-Grail-Layout für Contao

[Sebastian]

HI

Die Erweiterung holygrail setzt das Holy-Grail-Layout von A List Apart für TYPOlight um.

Das Contao-CSS-Framework sieht im Quelltext die Spaltenreihenfolge Linke Spalte | Rechte Spalte | Hauptspalte vor. Diese werden dann per CSS so angeordnet, dass der Benutzer sie in der Folge Linke Spalte | Hauptspalte | Rechte Spalte sieht.

Bedenkt man jedoch, dass in der Hauptspalte meist der wichtigere Inhalt liegt, erscheint es sinnvoller, die Hauptspalte zuerst im Quelltext zu nennen, damit Menschen mit Behinderungen und Suchmaschinen diesen Inhalt zuerst sehen.

Durch das Holy-Grail-Layout lassen sich die Spalten in der Reihenfolge Hauptspalte | Linke Spalte | Rechte Spalte anordnen.

Die Erweiterung stellt ein neues Frontend-Template „fe_holygrail.tpl“ zur Verfügung, das im Seitenlayout ausgewählt werden kann. Sobald dieses, oder ein anderes mit „fe_holygrail“ beginnendes Template ausgewählt wurde, übernimmt die Erweiterung die Spaltenangaben aus dem Seitenlayout und erstellt damit einen neuen CSS-Block, der pro Seite eingebunden wird. Auch die Standard-CSS-Datei system/typolight.css wird durch eine abgewandelte CSS-Datei „holygrail.css“ ersetzt.

Ich habe in vielen Browsern unter Mac, Fedora und Windows getestet, aber besonders die IE-Hacks bereiten mir etwas Probleme. Ich würde mich also freuen, wenn v.a. Windows-Nutzer mir Feedback geben könnten, ob alles tut.

Aktuelle Version: 1.3.0

Sebastian

[jan.theofel]

Hi,

schöne Erweiterung. Damit kann man den Content noch besser für Suchmaschinen aufbereiten, weil die Inhalte zuerst kommen. Kommt damit in meine nun stetig zu überarbeitende Liste von Erweiterungen für SEO. Auch für Barrierfreiheit ist das natürlich optimal - aber das weißt du ja bereits. :-)

Jan

[Sebastian]

HI

Mir ging es gerade eher um die Barrierefreiheit, aber mit SEO lässt sich schließlich Geld verdienen…

Ich habe einen neuen Build erstellt, weil ich dummerweise alle .htaccess-Dateien vergessen hatte, das sollte nun behoben sein. Aber ich glaube, eine neue Freigabe wäre sinnvoller gewesen. Naja…

Sebastian

[Sebastian]

Version 1.0.0 RC2

HI

Ich habe gerade Version 1.0.0 RC2 der Erweiterung hochgeladen.

Das ist neu:

• Seitentemplate an Contao 2.9 angepasst
• Fehler in der deutschen Sprachdatei behoben

Ich bitte weiterhin um X-Browser-Testing und vor allem Rückmeldungen hier.

Sebastian

[thepixture]

Eine Frage, wenn ich diese Erweiterung in eine bestehende Contao-Webseiten installiere, muss ich dann nur das page-template einstellen, oder bedarf es noch weiterer Einstellungen?

@ETES: Mich würde Deine SEO-Liste mal interessieren

[Sebastian]

HI

Prinzipiell ändert sich sonst gar nichts, Template auswählen - fertig. Es kann aber natürlich sein, dass du dein CSS so seltsam aufgebaut hast, dass es zu Problem kommen könnte. ;-)

Zur SEO-Liste: http://www.contao.org/usertreffen-2010.html#agenda

Sebastian

[Sebastian]

Version 1.0.0 stable

HI

Ich habe gerade Version 1.0.0 stable der Erweiterung hochgeladen.

Das ist neu:

• Zusätzliches Seitentemplate „fe_holygrail_nocron.tpl“ (Aufruf der cron.php entfernt)
• Korrektur in der CSS-Datei holygrail.css

Sebastian

[Sebastian]

Version 1.1.0

HI

Ich habe gerade Version 1.1.0 stable der Erweiterung hochgeladen.

Das ist neu:

* Option hinzugefügt, die Datei holygrail.css nicht im Frontend einzubinden
* iefixes.css wird nicht mehr eingebunden (konnte zu Problemen führen), bei Bedarf selbst einbinden

Zur ersten Option: Für die Optimierung der Seitengeschwindigkeit ist es nützlich, alle CSS-Dateien in einer einzigen Datei zusammenzufügen.
Dazu kannst du die Inhalte der Datei holygrail.css in deine eigenen Stylesheets übernehmen, und im Seitenlayout über die neue Option „CSS-Datei nicht einbinden“ die Datei holygrail.css aus dem Frontend entfernen – ein Aufruf weniger, einige Millisekunden schnelleres Laden.

Sebastian

[jan.theofel]

Hi Sebastian,

sehr schön: Damit kann man in Zukunft alles CSS in einer Datei führen und so unnötige HTTP-Requests sparen. Kann auch das Inline-CSS noch in dieser Weise behandelt werden?

Jan

[Sebastian]

HI

Das wird eher schwierig, weil diese Anweisungen ja nach Seitenlayout unterschiedlich sein können. Die Option könnte ich schon hinzufügen, aber ob das sinnvoll ist?

Inline-CSS verursacht ja auch keine neuen HTTP-Requests, ich halte das dann eher für eine (übereifrige) Schönheitskorrektur…

Sebastian

[jan.theofel]

Hi Sebastian,

ich denke die meisten Webseiten wird meistens mit einem fixen Layout pro Theme gearbeitet, selten mehr.

Sprich ich könnte mir einmal den CSS-Code im Backend "zusammenklicken", dann den Inline-CSS kopieren, als CSS-Code im Backend hinzufügen und dann das Inline-CSS in der Erweiterung deaktivieren.

Vorteil: Der Code der Seite wird noch schlanker und kompakter.

Jan

[Sebastian]

HI

Ich kenne einige Seiten, deren Kopfzeile beispielsweise auf der Startseite eine andere Höhe hat als auf Unterseiten. Das ginge dann wohl über Body-Klassen.

Aber was hältst du davon: Wenn du im Seitenlayout alle Angaben zu Spaltenbreiten und statischem Layout entfernst, wird kein Inline-CSS mehr generiert, und du kannst den nötigen Code in ein Stylesheet auslagern.

Sebastian

[jan.theofel]

Hi,

ok, den Fall gibt es in der Tat. Aber auch dann sind es meistens nur zwei verschiedene Layouts, was diese Werte angeht.

Alles entfernen führt dazu, dass ich es mir zum einen nicht mehr im Frontend "zusammenklicken" kann und zum anderen dazu, dass ich die Werte bei einer Umstellung alle manuell rausnehmen muss statt einfach eine Checkbox zu setzen.

Ich habe das mal schnell implementiert. Anbei der angepasste Code.

Jan

[Sebastian]

HI

Ich habe gerade Version 1.2.0 stable der Erweiterung hochgeladen.

Das ist neu:

* Option hinzugefügt, das Inline-CSS nicht im Frontend einzubinden
* Bugfix: Bei leeren Angaben im Seitenlayout wurde die contao.css nicht überschrieben

Damit sollte Jan zufrieden sein

Sebastian

[jan.theofel]

Hi,

ja, bin ich. Danke! ;-)

Jan