right-div wird zuerst im quelltext angegeben

[sokranIT]

Hallo Leute,

ich habe jetzt erfolgreich das TL eingesetzt und es funktioniert alles supi - SUPER CMS, danke dafür -
Jaschienenetzt arbeite ich an der Suchm-Freundlichkeitsoptimierung der Seite und demnach sollte der Wichtigster Content so weit wie möglich im Quelltext stehen.

Ich habe das SeitenLayout mit einer rechten Spalte gewählt und was passiert ist, dass dieser div mit der ID right (hat eher weniger wichtigkeit als der main-div) im quelltext höher erscheint. Kann man das ändern?

Kann man dem TL sagen, dass der "right" div im code nach dem "main" kommt?

danke im Voraus

Grüsse

[Oden]

Sorry, ich verstehe nicht ganz. Du willst, daß die Positionen der CSS-Regeln im Quelltext anders angeordnet sind? Oder meinst du doch eher, daß es Probleme bei der Darstellung deiner Seite gibt?!?!
Ein Link, oder zumindest ein Screen wäre nicht schlecht.


cu.Oden

[sokranIT]

Hi - sorry - ich versuchs einfacher auszudrücken:

im Quellcode (html...) steht zuerst

<div id="right">...</div> 
<div id="main">...</div>

da google nach Präorität von oben nach unten den Code durchgeht, möchte ich dass es so aussieht:

<div id="main">...</div> 
<div id="right">...</div>

hier ein Link: www.arne-tode.com

Danke im Voraus

[lucina]

Moin,

ich persönlich halte Deinen Punkt mit 'Google' da ja für weniger relevant, aber wenn Du das ändern möchtest, dann ist das jetzt einer der Momente, in dem Du die Datei 'fe_page' überschreiben kannst:

- Backend -> Layout -> Templates -> 'neues Template' aus Vorlage 'fe_page' erstellen
- in diesem die Reihenfoge von '<div id="right"> etc. und <div id="main"> etc. tauschen. Bei der Gelegenheit ggf. die Schleifen mit '<?php if ($this-> ...' sowie den Bereich mit '<?php if ($this->left ...' mt entsorgen, so Du den nicht brauchst.

Deine Bereiche sollten dann in der für Dich richtigen Reihenfolge im Quelltext erscheinen. Es hat dann allerdings den Nachteil, dass Du bei Systemupdates ggf. schauen musst, ob sich etwas in der Originalen 'fe_page.tpl' geändert hat - und diese Änderungen ggf. per Hand in Deine 'fe_page' nachtragen müsstest.

Für mich wäre es den Aufwand nicht wert ...

Carolina.

[sokranIT]

danke dir - ja dann muss ich wohl die anpassen...
hoffe das deisgn bleibt dann auch so stehen

Grüsse - SokranIT

[Oden]

Es gibt Style-Regeln, da kann man nicht einfach so die DIVs tauschen. Je nach dem, wie die float's gesetzt sind. Ich weiß zwar jetzt nicht wie die das bei TL geregelt ist (selbst noch nicht getestet), aber ich möchte damit nur sagen, daß dies hier nicht unbedingt funktionieren muß!
Zum Bsp. wenn man einen Footer-Div gleich nach dem Body einfügt und dieser auf fixed gesetzt ist und gleichzeitig auf bottom:0;, spielt es keine Rolle wo der im Quellcode steht.


co.Oden

[sokranIT]

ja stimmt auf jeden fall - was mich nur stört ist dass TL den Main div als "position:relative" gesetzt hat und den rechten als "float:right".... wenn der main "float:left" hätte würde alles gut sein, aber so...

naja muss jetzt mal schauen wie ich das hinkriege

Danke vielmals

[tril]

@sokranIT: Mal eine ganz andere Frage, wie kommst du darauf das Google den Quellcode von der Reihenfolge in der Datei priorisiert?! Hast du dazu eine Referenz, ich wüsste nicht das ich das so jemals im Inet noch in einem Buch über SEO je gelesen hätte?! (Außnahme sind die Meta Tags wie title, description und keywords, die Reihenfolge dieser Tags und ihres Inhaltes sind für Google relevant).

Zurück zum Thema:
- Warum stört dich position:relative? position:relative & float lässt sich doch ohne Probleme kombinieren.
- Setze, wenn du es wirklich so "umsortieren" möchtest doch einfach main { float: left; } in dein CSS

[MacKP]

@sokranIT: Mal eine ganz andere Frage, wie kommst du darauf das Google den Quellcode von der Reihenfolge in der Datei priorisiert?! Hast du dazu eine Referenz, ich wüsste nicht das ich das so jemals im Inet noch in einem Buch über SEO je gelesen hätte?! (Außnahme sind die Meta Tags wie title, description und keywords, die Reihenfolge dieser Tags und ihres Inhaltes sind für Google relevant).

Zurück zum Thema:
- Warum stört dich position:relative? position:relative & float lässt sich doch ohne Probleme kombinieren.
- Setze, wenn du es wirklich so "umsortieren" möchtest doch einfach main { float: left; } in dein CSS

Die Position der Meta-Tags innerhalb des Headers sind irrelevant. Wichtig ist die Position der Schlüsselwörter innerhalb dieser Tags.

Wichtig ist für Google auch der Inhalt der am anfang einer Seite steht... wenn da immer wieder die Navigation ist, wirkt sich das nicht positiv aus. Denn Google geht davon aus, das Wichtiger Inhalt am Anfang eines Textes steht. Allerdings kann Google nicht 'erkennen' was Navi und was Text ist in dem Sinne. Von daher kann ich den Wunsch schon verstehen. Davon ab wirst du ähnliches in vielen SEO Büchern / Quellen finden. Im gegensatz dazu wirst du dann auch finden, das Keywords (Meta-Tags) sowas von unwichtig geworden sind, das man die vernachlässigen kann und für Google auch ganz weglassen kann.

Umsortiert werden soll hier auch erst mal 'nur' der Quelltext und danach die Position im CSS. Der Weg das über das Template zu machen ist genau der richtige. Daher bevorzuge ich auch ein anderes Framework als das TL eigene.. man ist dadruch durchaus flexiebler was solche Dinge angeht.

Viele Grüße

[chris]

Prinzipiell gilt ja, wer seine Website barrierearm gestaltet, macht nicht nur Behinderten, sondern auch den SUMas das Leben leichter und das wird immer honoriert.
Ein Crawler ist nichts anderes als ein Blinder. Beide erfassen zunächst einmal das Markup und wer sich mal Webseiten von entsprechender Software hat vorlesen lassen, der weiß wie wichtig es ist, den eigentlichen Inhalt nicht in den Tiefen des fürs Formatieren notwendigen Div-Süppchens zu verbergen

Ach, gäbe es doch eine Möglichkeit, schnell zum eigentlichen Inhalt der Seite zu springen

.

[MacKP]

Prinzipiell gilt ja, wer seine Website barrierearm gestaltet, macht nicht nur Behinderten, sondern auch den SUMas das Leben leichter und das wird immer honoriert.
Ein Crawler ist nichts anderes als ein Blinder. Beide erfassen zunächst einmal das Markup und wer sich mal Webseiten von entsprechender Software hat vorlesen lassen, der weiß wie wichtig es ist, den eigentlichen Inhalt nicht in den Tiefen des fürs Formatieren notwendigen Div-Süppchens zu verbergen .

Hallo chris,
Div-Süppchen sind an sich kein Problem für Screenreader. Wenn man für die Formatierung noch ein Div um etwas macht um zum Beispiel einen Schatten besser Positionieren zu können ist das unrelevant und wird nicht vorgelesen. Divs werden einfach nicht vorgelesen...
Was wichtig ist, ist die Reihenfolge (und dann eben auch Skiplinks, Landmarks bzw. role Zuweisungen der verschiedenen Bereiche). Da hat die so genannte Div-Soup nichts mit zu tun. Eine Div-Soup entsteht, wenn man Anstelle einer anderen sinnvollen Auszeichnung Divs benutzt. Zum Beispiel eine Liste mit Divs ersetzt...

Das nur dazu, damit der Begriff und das was dahinter steckt nicht missverstanden wird.

Viele Grüße

[sokranIT]

Die Position der Meta-Tags innerhalb des Headers sind irrelevant. Wichtig ist die Position der Schlüsselwörter innerhalb dieser Tags.

Wichtig ist für Google auch der Inhalt der am anfang einer Seite steht... wenn da immer wieder die Navigation ist, wirkt sich das nicht positiv aus. Denn Google geht davon aus, das Wichtiger Inhalt am Anfang eines Textes steht. Allerdings kann Google nicht 'erkennen' was Navi und was Text ist in dem Sinne. Von daher kann ich den Wunsch schon verstehen. Davon ab wirst du ähnliches in vielen SEO Büchern / Quellen finden. Im gegensatz dazu wirst du dann auch finden, das Keywords (Meta-Tags) sowas von unwichtig geworden sind, das man die vernachlässigen kann und für Google auch ganz weglassen kann.

Umsortiert werden soll hier auch erst mal 'nur' der Quelltext und danach die Position im CSS. Der Weg das über das Template zu machen ist genau der richtige. Daher bevorzuge ich auch ein anderes Framework als das TL eigene.. man ist dadruch durchaus flexiebler was solche Dinge angeht.

Viele Grüße

Hallo - genau das habe ich auch in erinnerung - daher werde ich auch das umschreiben. main = float:left und right:float:right (ohne margin )

Danke nochmals

[chris]

Hallo chris,
Div-Süppchen sind an sich kein Problem für Screenreader. ... Eine Div-Soup entsteht, wenn man Anstelle einer anderen sinnvollen Auszeichnung Divs benutzt. Zum Beispiel eine Liste mit Divs ersetzt...

Das nur dazu, damit der Begriff und das was dahinter steckt nicht missverstanden wird.

Viele Grüße

Sorry, ich dachte mit einem subtilen Hinweis auf weitere Markupinkonsistenzen könnte ich dem Prinzip strukturell wichtige Inhaltsteile zuoberst zu positionieren noch Nachdruck verleihen. Dass du das aber auch gleich so auseinandernehmen musst....

[MacKP]

Sorry, ich dachte mit einem subtilen Hinweis auf weitere Markupinkonsistenzen könnte ich dem Prinzip strukturell wichtige Inhaltsteile zuoberst zu positionieren noch Nachdruck verleihen. Dass du das aber auch gleich so auseinandernehmen musst....

Hallo chris,
tut mir leid. Ich versuch nur möglichst solche Begriffe passend mit Leben zu füllen, da es schon genug Quellen gibt die das nicht ganz richtig darstellen. Und viele greifen dann so etwas auf (kann ich gut verstehen, ich hatte das am Anfang auf falsch verstanden...) und bilden sich dann ihre Meinung. Und wenn die erst einmal fest steht wirds schwierig dem entgegenzuwirken ;-)

Außerdem ist heute Sonntag und ich hatte keine Lust produktiv zu Arbeiten. Also hatte ich zeit mal etwas mehr zu schreiben *g*

Viele Grüße

[chris]

Du hast ja vollkommen Recht... war mein Fehler.

Aber zurück zur semantischen Struktur. Gibt es da ein Problem TL von vornherein ein barriereärmeres Markup zu spendieren? Immerhin heißt es ja auf der Startseite:

Barrierefreies Content Management System

Bei diesen Ambitionen wäre es vielleicht nicht unangemessen den Focus vor allem in der Umsetzung dessen im Frontend zu realisieren. Ich weiß nicht, evtl. gibt es ja auch Gründe, die dagegen sprechen. Ist das so?

[xchs]

Ich weiß nicht, evtl. gibt es ja auch Gründe, die dagegen sprechen. Ist das so?

An und für sich spricht nichts dagegen. Ich für meinen Teil verwende z.B. auch ein angepasstes Seitentemplate mit einer in dieser Hinsicht optimierten Spaltenanordnung.
Ich kann aber auch Leo sehr gut verstehen, wenn er mit diesbezüglichen Änderungen an Templates bzw. Core-Dateien zurückhält, zumal davon viele, zum Teil auch ältere/bestehende Projekte und Webseiten betroffen wären...

[MacKP]

Du hast ja vollkommen Recht... war mein Fehler.

Aber zurück zur semantischen Struktur. Gibt es da ein Problem TL von vornherein ein barriereärmeres Markup zu spendieren? Immerhin heißt es ja auf der Startseite:



Bei diesen Ambitionen wäre es vielleicht nicht unangemessen den Focus vor allem in der Umsetzung dessen im Frontend zu realisieren. Ich weiß nicht, evtl. gibt es ja auch Gründe, die dagegen sprechen. Ist das so?

Da hast du nicht ganz unrecht.
Zum Glück gibts im Team Nina, die da sehr drauf achtet
Ich glaube nicht das es so große Chancen gibt das es geändert wird, da man es ja selber ändern kann, Barrierefreiheit eh nicht Manschinell ereichbar ist und man eh irgendwo anpassen muss (um z.B. eine Skiplink Navi zu bekommen die vernünftig ist).
Von daher ist auch mit der Umstellung nicht viel gewonnen.

Ansonsten kannst ja mal hier schauen -> https://community.contao.org/de/show...light+wirklich
Eventuell wird dann einiges klarer zum Umgang von leo mit solchen Dingen ;-)

Viele Grüße

[chris]

Danke fürs nachträgliche Verlinken... hatte die Diskussion nämlich erstmal nicht gefunden.

Habs komplett durchgelesen und mir wird jetzt ein bisschen klarer wie die Fronten verteilt sind

Nun gut, der Begriff Barrierefreiheit dient hier sicherlich auch einem Promotioneffekt, denn mit "out of the box schon relativ barrierearm" lockt man ja keinenn Hund hinterm Ofen hervor. Ich denke Leo hatte bei deiner Anregung wohl auch nicht gerade einen guten Tag erwischt und ist beim Aufstehen vielleicht über eine Barriere gestolpert

Denkst du er wäre total abgefuckt, wenn man nun noch einen Schritt weiterginge und mit Barrierefreiheit auch eine verbesserte Leserlichkeit für Blinde out of the box in Verbindung brächte?

[MacKP]

Hallo chris,
ich kann da leider nicht viel zu sagen, ob das angenommen wird oder nicht.
Wenn man gute Gründe vorbringt und aufzeigen kann das es wirklich etwas bringen würde, dann glaub ich schon das es klappen könnte.
Andererseits glaube ich das man an so einem Punkt eh am Template Änderungen vornemen muss.. von daher könnte es auch durchaus sein das es deswegen eh abgelehnt wird.

Aber ohne das zu versuchen werden wir es nie wissen

Also versuch es einfach mal.

Viele Grüße

[chris]

Mich beschleicht ja so langsam das Gefühl, dass du mich für deine Zwecke mißbrauchen willst
Vielleicht wärs besser wir gründen hier im Forum die Fraktion Barrierefreiheit und sammeln Unterschriften für ein besseres TL, bevor sich einer von uns dann stellvertretend für alle traut ein Ticket zu ziehen

[MacKP]

Mich beschleicht ja so langsam das Gefühl, dass du mich für deine Zwecke mißbrauchen willst
Vielleicht wärs besser wir gründen hier im Forum die Fraktion Barrierefreiheit und sammeln Unterschriften für ein besseres TL, bevor sich einer von uns dann stellvertretend für alle traut ein Ticket zu ziehen

Hallo chris,
versteh mich da nicht falsch, ich will dich da überhaupt nicht missbrauchen ;-)

Noch mal zur Verdeutlichung: Ich bin der Meinung das dieses feature eher was mit SEO zu tun hat. Für Barrierefreie Seiten gibt es noch andere Möglichkeiten (wo man eh ans Template für muss).
Mir selber ist das ziemlich egal ob dieses feature nun in TL kommt oder nicht. Ich bearbeite eh jede meiner Seitentemplates, da ich ein anderes CSS-Framework nutze (eben auch wegen solchen Dingen und weiterführenden, die in dem Framework bedacht sind).

Es ist nur so, das wenn du kein Ticket schriebst es wahrscheinlich keiner machen wird. Also mach es einfach. So schlimm ist es auch nicht, wenn leo einem ne Absage erteilt *g*

Viele Grüße

[chris]

Ich bin der Meinung das dieses feature eher was mit SEO zu tun hat. Für Barrierefreie Seiten gibt es noch andere Möglichkeiten (wo man eh ans Template für muss).

Wenn der Hauptinhaltscontainer im Markup des Templates ganz oben steht wie zB. hier, dann hilft das aber nicht nur der SEO sondern noch viel mehr der Barrierefreiheit. Auf weitere Skiplinks könnte man dann sogar ganz verzichten. Oder sehe ich da was grundsätzlich falsch?

Mir selber ist das ziemlich egal ob dieses feature nun in TL kommt oder nicht. Ich bearbeite eh jede meiner Seitentemplates, da ich ein anderes CSS-Framework nutze (eben auch wegen solchen Dingen und weiterführenden, die in dem Framework bedacht sind).

Naja, aber es kann doch nicht Sinn der Sache sein, ein bzgl. Barrierefreiheit verbesserungswürdiges Framework in TL zu implementieren, an anderer Stelle dann aber davor zu warnen, wegen Updatesicherheit lieber nicht eigene Templates zu nutzen.

[MacKP]

Wenn der Hauptinhaltscontainer im Markup des Templates ganz oben steht wie zB. hier, dann hilft das aber nicht nur der SEO sondern noch viel mehr der Barrierefreiheit. Auf weitere Skiplinks könnte man dann sogar ganz verzichten. Oder sehe ich da was grundsätzlich falsch?

Das Problem dabei ist: wenn das die Einstiegsseite ist (kann ja jede Seite sein) braucht man in jedem Fall einen Skiplink o.ä. zur Navigation.. in dem anderen Fall einen Skiplink zum Inhalt. So oder so.... nur eben aus anderer Sicht ;-)
Oder auch andere Auszeichnungen (role).

Naja, aber es kann doch nicht Sinn der Sache sein, ein bzgl. Barrierefreiheit verbesserungswürdiges Framework in TL zu implementieren, an anderer Stelle dann aber davor zu warnen, wegen Updatesicherheit lieber nicht eigene Templates zu nutzen.

Ja, es wird immer davor gewarnt Templates zu ändern wenn man nicht weiß was man macht. Denn sonst macht man ein update und wundert sich das es nicht so richtig rund läuft.
Der Knackpunkt ist in dem Fall hier -> 'wenn man nicht weiß was man macht'
Wenn man es weiß kann und sollte man es machen. Sonst hat man zum Beispiel bei den News o.ä. die Falsche Überschrift (ich glaub Standard ist da im Moment noch h1).

TL ist meiner Meinung nach extra so aufgebaut das man Templates ändern kann und soll. Sonst hätte man nicht die Möglichkeit Templates auszuwählen (leider nicht überall) und diese Updatesicher zu ändern. Das ganze soger per Klick im Backend.
Auch leo schreibt sehr häuig das dafür die Templates sind. So häufig, das der Schluss nahe liegt, das er es auch ähnlich sieht.

Dem Gegenüber steht dann aber auch das was du ansprichst. TL hat sich auf die Fahne geschrieben dies und jenes zu sein. Wann es aber nun so oder so ist wird nur leo sagen können. Daher immer noch meine Bitte: Schreib nen Ticket ;-)

Viele Grüße

[chris]

Das Problem dabei ist: wenn das die Einstiegsseite ist (kann ja jede Seite sein) braucht man in jedem Fall einen Skiplink o.ä. zur Navigation.. in dem anderen Fall einen Skiplink zum Inhalt. So oder so.... nur eben aus anderer Sicht ;-)
Oder auch andere Auszeichnungen (role).

Das sehe ich anders. Es gibt ja bereits den Navigationsskiplink im TL Core. Wenn man also direkt nach der Navi den Hauptinhtscontainer hätte, wozu denn dann bitteschön einen Skiplink zum Inhalt?
Einen Skiplink "zurück" oder "nach oben" das sehe ich ja noch ein, das machen ja sowieso die meisten sogar ohne ihn zu verstecken.

Ja, es wird immer davor gewarnt Templates zu ändern wenn man nicht weiß was man macht. Denn sonst macht man ein update und wundert sich das es nicht so richtig rund läuft.
Der Knackpunkt ist in dem Fall hier -> 'wenn man nicht weiß was man macht'
Wenn man es weiß kann und sollte man es machen. Sonst hat man zum Beispiel bei den News o.ä. die Falsche Überschrift (ich glaub Standard ist da im Moment noch h1).

Ja, dieser H1 bei den News hat auch gleich meinen ersten Eindruck von TL geprägt...!!!
Schon erstaunlich wie smart TL aufgebaut ist und dann aber so ein Template reingeknallt wird.

TL ist meiner Meinung nach extra so aufgebaut das man Templates ändern kann und soll.

Aso, deiner Meinung nach Ja ne schon klar.

Sonst hätte man nicht die Möglichkeit Templates auszuwählen (leider nicht überall) und diese Updatesicher zu ändern. Das ganze soger per Klick im Backend.

... sagen wir mal in den meisten Fällen updatesicher.

Auch leo schreibt sehr häuig das dafür die Templates sind. So häufig, das der Schluss nahe liegt, das er es auch ähnlich sieht.

Er muss es ja so sehen. Das mit dem H1 in den News ist ja im Prinzip eine Aufforderung gefälligst Templates anzupassen! Auch wenn man jetzt nciht so auf Barrierefreiheit Wert legt, validen Code will man dann meistens schon haben.

Dem Gegenüber steht dann aber auch das was du ansprichst. TL hat sich auf die Fahne geschrieben dies und jenes zu sein. Wann es aber nun so oder so ist wird nur leo sagen können. Daher immer noch meine Bitte: Schreib nen Ticket ;-)

Du lässt nicht locker

[MacKP]

Das sehe ich anders. Es gibt ja bereits den Navigationsskiplink im TL Core. Wenn man also direkt nach der Navi den Hauptinhtscontainer hätte, wozu denn dann bitteschön einen Skiplink zum Inhalt?
Einen Skiplink "zurück" oder "nach oben" das sehe ich ja noch ein, das machen ja sowieso die meisten sogar ohne ihn zu verstecken.

Naja, da fängts dann schon wieder an:
Der Skiplink sagt einem nur: Navigation Überspringen
Na wo gehts denn da hin? Ich weiß das nicht wenn ich zum 1. mal auf der Seite bin
Dann gibts ja durchaus noch ne Unternavigation an einer anderen Stelle oder andere Spannende Stellen auf die eventuell geskiplinkt werden sollte/könnte.
Das reicht dann also nicht.
Davon ab wolltest du doch den #main Bereich durchaus auch am Anfang einer Seite haben?

Ja, dieser H1 bei den News hat auch gleich meinen ersten Eindruck von TL geprägt...!!!
Schon erstaunlich wie smart TL aufgebaut ist und dann aber so ein Template reingeknallt wird.

Ja, da war er ja bisher anderer Ansicht beim Aufbau von Überschriften (wird in 2.9.0 geändert, da Nina zum Glück nicht locker gelassen hat in einem Ticket).

Aso, deiner Meinung nach Ja ne schon klar.

Naja, ist nicht nur Meine. Aber ich kann an sich ja immer nur für mich selber sprechen.

... sagen wir mal in den meisten Fällen updatesicher.

Hmm.. Sie sind updatesicher. D.h. die Dateien gehen nicht verlohren. Man muss durchaus mal wieder ran und was anpassen. Aber das ist was anderes

Er muss es ja so sehen. Das mit dem H1 in den News ist ja im Prinzip eine Aufforderung gefälligst Templates anzupassen! Auch wenn man jetzt nciht so auf Barrierefreiheit Wert legt, validen Code will man dann meistens schon haben.

Achja, Valide ist der Code immer noch mit H1. Da gehts dann eher um Semantik und Accessibility

Du lässt nicht locker

Ich lasse nicht locker weils der einzige Weg ist.
Schau dir an was hier passiert. Wir beide unterhalten uns prächtig. Aber es hilft einfach nicht ^^
Genau deswegen schreib ich dir das immer wieder und versuche dich zu ermutigen. Das ist eben OpenSource auch: jeder kann mitmachen!
Und ich steh dazu, das auch jeder Mitmachen sollte, der es kann. Dadurch wirds nur besser, da sich jeder in seinem Bereich am besten auskennt, bekommt man so ein gutes ganzes.
Naja, Philosophieren bringt jetzt hier auch nichts, außer das ich vom Thema abkomme.

Viele Grüße

[chris]

Naja, da fängts dann schon wieder an:
Der Skiplink sagt einem nur: Navigation Überspringen

Genau, man merkt ja dann schnell, was danach kommt. Und wenn dann der Inhalt kommt oder zuvor noch ne Unternavigation, dann is doch alles super, denn beides deckt TL ab.

Davon ab wolltest du doch den #main Bereich durchaus auch am Anfang einer Seite haben?

Sagen wir mal relativ am Anfang. Entweder nach dem menü oder halt auch davor, je nach dem, dann bräuchte man allerdings in TL einen händischen Skiplink zum Menü. Aber Wenn der Inhalt erst später kommt, dann werden die Barrieren immer größer.

Man muss durchaus mal wieder ran und was anpassen. Aber das ist was anderes

Das is für mich nichts anderes. Erst wenn man nicht mehr im Code nacharbeiten, anpassen oder sonstwas muss, ist für mich etwas updatesicher.

Achja, Valide ist der Code immer noch mit H1

Sorry, wieso hab ich eigentlich valide geschrieben? Natürlich meinte ich semantisch

Ich lasse nicht locker weils der einzige Weg ist.

Nein nein, da gibts noch viel andere:

• Korruption
• Bedrohung
• oder auch einfach gezielte Aussagenlogik, ohne gruppendynamische Elemente

Wieso hast du als dir nicht das Leben leichter machen wollen und einfach mal zur dritten Variante gegriffen, bezüglich des Startseitenproblems, oder der Markup Semantik, oder der strukturellen Gliederung?

[MacKP]

Das is für mich nichts anderes. Erst wenn man nicht mehr im Code nacharbeiten, anpassen oder sonstwas muss, ist für mich etwas updatesicher.

Ok, das ist eine Andere Sichtweise. Kann ich verstehen. Seh ich nicht ganz so, vor allem sehe ich da eher massive Probleme die dadurch kommen. Mir ist es da lieber wesendlich flexiebler zu sei. Denn ich Glaube das wird dann auf der Strecke bleiben. Und das fände ich Schade.

Nein nein, da gibts noch viel andere:

• Korruption
• Bedrohung
• oder auch einfach gezielte Aussagenlogik, ohne gruppendynamische Elemente

Wieso hast du als dir nicht das Leben leichter machen wollen und einfach mal zur dritten Variante gegriffen, bezüglich des Startseitenproblems, oder der Markup Semantik, oder der strukturellen Gliederung?

Hmm versteh ich jetzt nicht ganz glaube ich ^^
Du meinst ich hätte mit meinen Tickets mehr erreicht, wenn ich gezielte Aussagenlogik genutzt hätte?
Ich dachte das hätte ich gemacht *g*

Oder fragst du dich warum ich nicht auch hiervon ein Ticket mache?
Naja, ich hab schon genug zu tun indem ich hier support gebe und versuche darüber TL als ganzes besser zu machen

Viele Grüße

[chris]

Ok, das ist eine Andere Sichtweise. Kann ich verstehen. Seh ich nicht ganz so, vor allem sehe ich da eher massive Probleme die dadurch kommen

Also angenommen die TL Templates erfüllen für ein bestimmtes Seitenlayout alle Bedingungen für Barrierefreiheit. Du hast die Wahl das zu nehmen und brauchst dich bei Updates um ncihts zu kümmern oder du kannst dir davon unabhängig immer noch ein anderes stricken... wo ist denn da das Problem jetzt?

Ich dachte das hätte ich gemacht *g*

Ach ja? Da interessieren mich jetzt aber die Reaktionen darauf. Hast du Links?

Naja, ich hab schon genug zu tun indem ich hier support gebe

Du hilfst hier wirklich sehr vielen Leuten, ich bin beeindruckt. Ich frage mich weshalb dich Leo - ich drücks mal diplomatisch aus - dennoch so abgebügelt hat in dem Thread bzgl. Barrierefreiheit?

[MacKP]

Also angenommen die TL Templates erfüllen für ein bestimmtes Seitenlayout alle Bedingungen für Barrierefreiheit. Du hast die Wahl das zu nehmen und brauchst dich bei Updates um ncihts zu kümmern oder du kannst dir davon unabhängig immer noch ein anderes stricken... wo ist denn da das Problem jetzt?

Hmm, da habe ich natürlich nichts dagegen. Aber wie ich schon einmal geschrieben habe: Ich glaube nicht das man automatisch alles passend machen kann. Es wäre schön wenn das gehen würde. Dann wäre das Web um einiges Besser.
Natürlich kann man immer versuchen das Optimum zu erreichen. Dagegen habe ich natürlich auch nichts

Mit anderen Worten: Ich habe sicherlich kein Problem damit. Aber auf mich kommts auch nicht an *g*
Ich persönlich nutze für mich ja auch Methoden um das zu erreichen was ich möchte.

Ach ja? Da interessieren mich jetzt aber die Reaktionen darauf. Hast du Links?

Ne, da hab ich keine direkten Links mehr.. waren Tickets, die ich gemacht hatte bevor ich den Thread geschrieben hatte (eben zu den Themen die ich in dem Thread zur Barrierefreiheit angesprochen hatte).

Du hilfst hier wirklich sehr vielen Leuten, ich bin beeindruckt. Ich frage mich weshalb dich Leo - ich drücks mal diplomatisch aus - dennoch so abgebügelt hat in dem Thread bzgl. Barrierefreiheit?

Tja, das große Warum. Da kann ich dir auch keine Antwort zu geben. Ich kenne leo bisher nicht persönlich, kann also nicht sagen wann er warum wie reagiert (und auch wenn ich ihn kennen würde, kann man sowas nur schwer sagen, wenn man jemanden nicht schon ein paar Jahre sehr gut kennt).
Was ich mir allerdings so erst mal denken könnte: leo hat viel Zeit und mehr in TL investiert. Hat sich durchaus sicher auch viele Gedanken gemacht. Wenn dann (in dem Fall ein Fremder) daher kommt und groß redet ohne selber so etwas machen zu können... dann kann es durchaus schon passieren, das man erst einmal etwas abwehrend reagiert.
Das was man dann machen kann, ist jemanden vom Gegenteil zu überzeugen. Bei vielen Punkten ist es uns und vor allem Nina dann doch im Ticket System gelungen. Und das ist der Punkt der zählt. Zum Schluss wurde erreicht was angesprochen wurde. Der Weg ist danach nur noch Nebensache.

Viele Grüße

----
Edit:
jetzt hab ich eine Sache glatt aus den Augen verlohren gehabt vom lauter diskutieren *g*

Und zwar wird leo die Grundlage des fe_page.tpl so gewählt haben, da es die stabielste und gleichzeitig flexiebelste Art ist ein Design umzusetzen. Einmal ist es allgemein einfacher Handhabbar (auch für Anfänger). Und andererseits ist es möglichst abwärtskompatibel.

Nicht umsonst gibt es für deine Wünsche z.B. beim Yaml-Framework extra Vorlagen, da diese dann nicht alles können, was diese Reihenfolge bietet.

So, jetzt kann ich beruhigt schlafen gehen ohne das im Kopf behalten zu müssen *g*

Viele Grüße

[chris]

Ich glaube nicht das man automatisch alles passend machen kann

Ich glaube für ein vordefiniertes Layout kann man alles weitestgehend passend machen. Wer ein anderes Layout möchte, der muss dann halt Templates/CSS ändern. Aber immerhin hätten dann auch Anfänger es wirklich barrierefrei wenn sie sich mit einer vorgegebenen Seitenstruktur zufrieden geben. Und erst dann kann man auch von barrierefrei sprechen.
Solange aber JEDER gezwungen ist, unabhängig vom Layout Anpassungen vorzunehmen, um zB. den Inhaltscontainer weiter nach oben zu verfrachten oder Skiplinks zu basteln, solange ist und bleibt das System out of the box nicht barrierefrei.

Der Begriff "barrierefrei" kann nicht beliebig interpretiert werden, da er schon von der Wortbedeutung her einen Absolutheitsanspruch hat, nämlich KEINE Barriere zuzulassen, sonst wäre er ja nicht "frei" davon! Auch nur die kleinste Behinderung im Zugang zu Informationen stellt streng genommen eine Barriere dar. Nun gibt es aber sicherlich Strukturen oder besondere Umstände, die prinzipbedingt nicht gänzlich barrierefrei umzusetzen sind. Es lässt sich trefflich darüber diskutieren ob das dann trotzdem barrierefrei bezeichnet werden darf oder nur noch barrierearm. Das führt aber in unserer Disussion zu weit. Wichtig ist nur eines, solange eine vorgegebene Struktur barriereärmer umgesetzt werden kann als sein status quo, kann sie per se nicht barrierefrei sein.
Und den Grund, weshalb der Inhaltscontainer im Markup nicht höher platziert wird, also mindestens nach der Navigation, den soll mir hier mal einer nennen.

[MacKP]

Hallo chris,
zu der Anordnung der Spalten kannst du dir ja mal das angucken ->http://www.yaml.de/de/dokumentation/...anordnung.html (Spaltenanordnung 2-1-3 und 3-1-2)

Da wirst du sehen, das die von dir bevorzugte Variante enorme Einschränkungen hat und daher nicht für alles gut genutzt werden kann.

Und ich möchte hier noch einmal wiederholen: den Inhalt nach oben zu schieben hat nicht wirklich etwas mit barrierefreiheit zu tun! Das ist immer noch ne SEO Sache... (Gründe habe ich oben schon genannt)

Ich muss dir in so fern recht geben, das ich mit der Umschreibung TL ist barrierefrei so meine Probleme habe. Es wäre schön, wenn TL zum Beispiel Hilfmittel an die Hand geben würde wo man sich eine skiplink Navigation zusammenbauen kann. Oder wenn TL schon role-Attribute unterstützen würde. Das wird es aber erst, wenn der W3C-Validator dabei nicht mehr meckert.

Viele Grüße

[chris]

Da wirst du sehen, das die von dir bevorzugte Variante enorme Einschränkungen hat und daher nicht für alles gut genutzt werden kann.

Barrierefreiheit und Flexibilitätsfreiheit sind Zielkonflikte. Man kann eben nicht beides haben und sollte entsprechend dem, was man sich auf die Fahne schreibt auch sein System stricken. Es geht aber nicht, dass man sich barrierefrei nennt, damit aber hochflexibel meint. Meines Erachtens nach ist hier der Ansatz also falsch gewählt. Entweder man lässt alles wie es ist und nennt es hochflexibel, oder man liefert ein bestimmtes Layout im Grundpaket, das tatsächlich barrierefrei ist, dafür aber unflexibler.

zu der Anordnung der Spalten kannst du dir ja mal das angucken ->http://www.yaml.de/de/dokumentation/...anordnung.html (Spaltenanordnung 2-1-3 und 3-1-2)

Mal abgesehen davon, dass es sich hier nur um ein 3 Spaltenlayout handelt (gibt ja auch andere) würde mich interessieren, wo nun genau die Nachteile nachzulesen sind. Auf der Seite fand ich nur folgenden Hinweis:

Oftmals besteht der Wunsch, den Inhalt einer Webseite möglichst weit vorn im Quelltext zu positionieren, während untergeordnete Elemente (Navigation, Sidebar usw.) weiter hinten im Quelltext erscheinen sollen. Zwar ist die Notwendigkeit dieser Maßnahme durchaus diskussionswürdig, aber dies soll nicht hier geschehen.

Und nun nochmals zu SEO vs Barrierefreiheit:

Und ich möchte hier noch einmal wiederholen: den Inhalt nach oben zu schieben hat nicht wirklich etwas mit barrierefreiheit zu tun! Das ist immer noch ne SEO Sache... (Gründe habe ich oben schon genannt)

Wenn in einem 3 spaltigen Layout der Hauptcontainer zuallerletzt kommt, also nach den Menüs und Seitenspalten, dann stellt das für alle nicht CSS formatierten Ausgabemedien schlicht und ergreifend eine Barriere dar. Unwichtige Seitenspalten mit Links oder sonstigem, die sowieso wiederholt vorkommen stören in solchen Fällen einfach mal. Man kann das mit Skiplinks halbwegs umgehen, aber solche sind ja nicht out of the box vorhanden, für das vorgegebene Markup.

[MacKP]

Mal abgesehen davon, dass es sich hier nur um ein 3 Spaltenlayout handelt (gibt ja auch andere) würde mich interessieren, wo nun genau die Nachteile nachzulesen sind. Auf der Seite fand ich nur folgenden Hinweis:

Ich habe es da auf die Möglichkeiten abgesehen, da bei so einer Anordnung das hier nicht möglich ist: 'Die Mischung verschiedener Einheiten fix (Pixel), flexibel (%) und elastisch (EM) zur Festlegung der Spaltenbreiten ist innerhalb eines Layouts möglich.'

Und nun nochmals zu SEO vs Barrierefreiheit:

Wenn in einem 3 spaltigen Layout der Hauptcontainer zuallerletzt kommt, also nach den Menüs und Seitenspalten, dann stellt das für alle nicht CSS formatierten Ausgabemedien schlicht und ergreifend eine Barriere dar. Unwichtige Seitenspalten mit Links oder sonstigem, die sowieso wiederholt vorkommen stören in solchen Fällen einfach mal. Man kann das mit Skiplinks halbwegs umgehen, aber solche sind ja nicht out of the box vorhanden, für das vorgegebene Markup.

Auch bei Text-basierten Browsern finde ich es nützlich nicht immer den Text an erster Stelle zu haben. Das ist wie ich oben schon meinte auch geschmackssache. Mittels Skiplink / role und anderen Mitteln kann man druchaus an solchen Stellen für ein angenehmes Browsen sorgen.
Ob eine Seitenleiste unwichtig ist, liegt in der Regel am Inhalt und nicht an der Tatsache das es an der Seite ist. Daher kann man das so pauschal einfach nicht sagen.

Aber ich seh schon, wir wiederholen unsere Argumente einfach nur. Da hat jeder von uns beiden einen etwas anderen Ansatz.
Mein Vorschlag bleibt also bestehen: wenn dich das so sehr Wurmt (und das scheint es, da du dir sonst nicht so viel Mühe geben würdest), dann schreib leo ein Ticket. Sonst war das alles hier umsonst.
Wenn ich ein Ticket schreiben sollte, dann würde ich da auf ein paar andere Dinge abziehlen und du hättest deinen Wunsch immer noch nicht wenn es durchgehen würde

Aber an sich bleibt noch zu sagen: ich weiß was du meinst, wir sind da mit unserer Meinung auch nicht so verschieden. Zumindest haben wir das selbe Ziel bzw. denken das selbe über barrierefreiheit in TL.
Wir stimmen aber nicht in allem 100% überein. Und das wird sich nicht ändern

Viele Grüße

[chris]

'Die Mischung verschiedener Einheiten

Beim Dreispaltigen is doch eh die %uale am wichtigsten, oder sehe ich das falsch? Dem Wrapper kann man doch so oder so ne feste Pixelbreite geben, wenn man ein px Layout imitieren möchte.

Auch bei Text-basierten Browsern finde ich es nützlich nicht immer den Text an erster Stelle zu haben

Manchmal habe ich aber auch das Gefühl du willst mich gerne falsch verstehen. Ich schrieb aber "nicht zu allerletzt", daraus muss man ja nicht gleich "an erster Stelle" machen. Warum malst du so Schwarzweiß? Es gibt doch auch Graustufen.

Ob eine Seitenleiste unwichtig ist, liegt in der Regel am Inhalt und nicht an der Tatsache das es an der Seite ist.

Ich berufe mich auf das aktuelle TL Template. Dort ist der Maincontainer ganz am Ende vorm Footer. Und wir wissen beide, dass die Wahrscheinlichkeit, dass in den beiden Seitenspalten #left #right wichtigeres stehen könnte als in #main, gegen NULL geht. Nicht umsonst heißt es "main", denn wichtiges packt man in die Mitte. Das macht jeder automatisch, weil es intuitiv ist, weil es gewohnt ist, weil es ergonoomisch ist weil es... ich machs kurz, dein Argument ist hinfällig. Oder du belehrst mich eines bessern und zeigst mir eine Seite, bei der Unwichtiges in die Mitte positioniert wird und Wichtiges an den Rand oder gar nach unten! Das ist doch fern jeder Haptik. Wir wollen doch jetzt nicht über so Augenscheinliches diskutieren? Immerhin geht es um ein Template, das eine möglchst große Nutzermenge so übernehmen könnte. Du redest aber von absoluten Spezialfällen, die ich unter die Rubrik: "Anpassungen notwendig" schieben würde.

Und nochmals, ich weiß dass man...

Mittels Skiplink / role und anderen Mitteln .... druchaus an solchen Stellen für ein angenehmes Browsen sorgen.

... kann. Mann kann alles, wenn man es händisch anpasst. Aber genau darum geht es doch. Wenn es sich barrierefrei nennt, dann sollte es das auch out of the box sein. Oder haben wir da aneinander vorbeigesprochen? Das ist doch auch das was du ständig bemängelst, wenn ich deinen Thread von Barrierefreiheit lese.

[MacKP]

Beim Dreispaltigen is doch eh die %uale am wichtigsten, oder sehe ich das falsch? Dem Wrapper kann man doch so oder so ne feste Pixelbreite geben, wenn man ein px Layout imitieren möchte.

es geht da eher um die Spalten an sich, das man da nicht der einen Spalte einen festen und der anderen einen Prozent Wert geben kann etc.

Manchmal habe ich aber auch das Gefühl du willst mich gerne falsch verstehen. Ich schrieb aber "nicht zu allerletzt", daraus muss man ja nicht gleich "an erster Stelle" machen. Warum malst du so Schwarzweiß? Es gibt doch auch Graustufen.

Ne, ist schon ok so. Ist eben ein Beispiel von vielen. Ich denke auch das es verschiedenste Möglichkeiten gibt.

Ich berufe mich auf das aktuelle TL Template. Dort ist der Maincontainer ganz am Ende vorm Footer. Und wir wissen beide, dass die Wahrscheinlichkeit, dass in den beiden Seitenspalten #left #right wichtigeres stehen könnte als in #main, gegen NULL geht. Nicht umsonst heißt es "main", denn wichtiges packt man in die Mitte. Das macht jeder automatisch, weil es intuitiv ist, weil es gewohnt ist, weil es ergonoomisch ist weil es... ich machs kurz, dein Argument ist hinfällig. Oder du belehrst mich eines bessern und zeigst mir eine Seite, bei der Unwichtiges in die Mitte positioniert wird und Wichtiges an den Rand oder gar nach unten! Das ist doch fern jeder Haptik. Wir wollen doch jetzt nicht über so Augenscheinliches diskutieren? Immerhin geht es um ein Template, das eine möglchst große Nutzermenge so übernehmen könnte. Du redest aber von absoluten Spezialfällen, die ich unter die Rubrik: "Anpassungen notwendig" schieben würde.

Naja, im Grunde könnte man #main und #right auch ziemlich klein machen, in #left dann den Hauptbereich, damit man ein Blog typisches Aussehen hat. Das wäre dann zum Besipiel so ein Fall.

Und nochmals, ich weiß dass man...
... kann. Mann kann alles, wenn man es händisch anpasst. Aber genau darum geht es doch. Wenn es sich barrierefrei nennt, dann sollte es das auch out of the box sein. Oder haben wir da aneinander vorbeigesprochen? Das ist doch auch das was du ständig bemängelst, wenn ich deinen Thread von Barrierefreiheit lese.

Nein, da reden wir eigentlich genau von dem selben. Wie ich oben schon erwähnt habe.
Allerdings ist es schwer da eine Grenze an einer bestimmten Stelle zu ziehen.
Wodrum es auf jeden Fall bei TL auch geht, ist das Backend und das dies Barrierefrei ist.
Wobei ich zugeben muss, das ich da noch nicht so genau geschaut habe. Das war bisher noch nicht so Nötig für die Seiten die ich gemacht habe.

Viele Grüße

[chris]

es geht da eher um die Spalten an sich, das man da nicht der einen Spalte einen festen und der anderen einen Prozent Wert geben kann etc.

Nun gut, da hast du ja Recht, aber das meinte ich damit, dass man eben nicht beides haben kann, Barrierefreiheit UND Flexibilität. Man muss sich für eine Variante entschließen.

Naja, im Grunde könnte man #main und #right auch ziemlich klein machen, in #left dann den Hauptbereich, damit man ein Blog typisches Aussehen hat. Das wäre dann zum Besipiel so ein Fall.

Nein, das wäre lediglich eine Vergewaltigung der Selektorenbezeichnungen und erfordert streng genommen eine Umsortierung der Container im Markup, um eine Konsistenz zwischen Inhalt, Markup und Formatierungsanweisungen herzustellen.

Ich zeige jetzt mal 3 mögliche Wege auf:

1. Weg.
Man könnte theoretisch Templates mit samt den zugehörigen CSS anbieten. Im Frontendtemplateverzeichnis gäbe es dann zB:

• fe_page_3col_liq.tpl
• fe_page_3col_px.tpl
• fe_page_2col_l_men.tpl
• fe_page_2col_r_men.tpl

... und in der Seitenstrukturauswahl die entsprechenden Bildchen zur Auswahl.

Klar, das System wird aufgeblähter, aber so ist das nunmal mit Software, je mehr Flexibilität, desto mehr Funktionen sind nötig und desto größer der Overhead. Anders herum könnte man auch rigoros sein und folgendes machen:

2. Weg.
Auf allen Schnickschnack verzichten, überhaupt keine Layoutoptionen anbieten und alles auf eine absolut barrierefreie Layoutkarte setzen, frei nach dem Motto ultraschlank, wenn dus anders haben möchtest, bau dir dein Template.

Die Aktuelle Handhabe liegt dagegen irgendwo dazwischen, hat nicht zuviel Overhead, ist von Barrierefreiheit und SEO dafür aber auch einen Schritt weiter weg. Alles legitim, es hat ja auch an anderer Stelle seine Vorteile, keine Frage. Nur lässt halt der Absolutheitsanspruch des Wortes Barrierefrei genau genommen keinen Interpretationsspielraum. Diesen nimmt sich Leo aber hier für das System heraus. Von daher wäre evtl. auch der folgende Weg in Betracht zu ziehen:

3. Weg.
Den Headliner ändern in: "Ultraflexibles und barrierearmes Open Source CMS", dazu dann aber am besten noch Tutorials anbieten, wie man sein Layout ganz barrierefrei gestaltet... oder vielleicht ein Buch veröffentlichen "TYPOlight barrierefrei und suchmaschinenoptimal einrichten". Und wer weiß, vielleicht schreibst ja dann DU dieses Buch

[MacKP]

Hallo chris,
mein Fav. wäre ja Methode 1, da ich die ja selber schon nutze (nur eben mit Yaml) *g*

Weg 2 ist glaube ich nicht wirklich gut gangbar. Es ist ja schon schwer genug für die meisten mit dem klar zu kommen was jetzt schon geboten wird.. da noch weniger draus zu machen wäre kein guter Schritt um das CMS weiter zu verbreiten ^^

Die 3. Möglichkeit fände ich ehrlich. Ich mags wenns ehrlich ist. Aber das ist eben mal so gar nicht Werbewirksam, auch wenn manch ein Webdesigner sicher froh wäre, wenn alle CMS etwas genauer und ehrlicher wären bei der Beschreibung was denn nun drinn ist. Das würde manchem die ein oder andere Testinstall sparen ;-)

Nen Buch... ach, da könnte ich auch noch über andere Themen schreiben.. der catalog wäre schon die hälfte von nem Dicken Buch *g*
Aber irgendwie drängt es mich eher zu frei verfügbareren Dingen... Naja, wer weiß ^^

Also:
Wie wäre es, wenn du mit diesen Vorschlägen einfach mal ein Ticket machst?
Ich glaub die Zeigen Mögliche Wege auf und leo könnte dadurch durchaus ans überlegen kommen ob es vllt günstig wäre den 1. beschriebenen Weg einzuschlagen.
Sowas würde eh noch einiges an vorarbeit benötigen, bis das Serienreif ist.
Da hat zum Beispiel Yaml mit dem Yaml-Builder und allem drum und drann schon so einiges vorgelegt und aufgezeigt wie es gehen kann.

Viele Grüße

[chris]

Methode 1 liegt viel zu nah, als dass er da nicht selbst schon drüber nachgedacht hätte. Ich gehe mal davon aus, er hat seine Gründe das bisher nicht gemacht zu haben. Ich glaube es macht evtl mehr Sinn Nina einfach mal nach den Gründen zu fragen, immerhin hat sie doch die Auszeichnung flotte Biene oder so gewonnen.

[MacKP]

Methode 1 liegt viel zu nah, als dass er da nicht selbst schon drüber nachgedacht hätte. Ich gehe mal davon aus, er hat seine Gründe das bisher nicht gemacht zu haben. Ich glaube es macht evtl mehr Sinn Nina einfach mal nach den Gründen zu fragen, immerhin hat sie doch die Auszeichnung flotte Biene oder so gewonnen.

Naja, auch Nina ist nicht leo... und nur leo wird seine Gedanken genau kennen ;-)

Viele Grüße