contao.css, iefix.css

[joad]

Hallo!

Ich oute mich jetzt mal als totaler Neuling und möchte auch sofort für einen Aufschrei sorgen: Ich hab mir als erstes einen Satz Templates gebaut :-)

Hintergrund: Das wird eine HTML5-Seite, und so richtig gepasst hat mir das alles nicht, also fix geändert - und es funktioniert auch alles sehr gut. Schöner Kickstart, kriegt man nicht bei jedem CMS so schnell hin.

Mein Problem im Moment: Ich komme mit meinen eigenen Styles ganz gut klar, jedoch wird immer die contao.css und die iefix.css mitgeladen. Da ich den Kram selbst style sind das zwei überflüssige Requests die ich gern loswerden würde.

Leider finde ich nirgends die Stelle wo ich das unterbinden könnte, kann mir jemand helfen?

[bubblez]

Verwendest du die html5boilerplate Erweiterung?

Eigentlich sollte contao.css im Frontend nicht eingebunden werden. Einstellbar wäre das im Backend in den Layout Einstellungen.

[Sebastian]

HI

Wenn du in deinem Template fe_*.tpl die Variable „$this->framework“ rausnimmst, verschwinden die beiden Dateien. Allerdings auch das Inline-CSS.

Sebastian

[wotank]

Allerdings auch das Inline-CSS.

was nicht wirklich schade ist, da es der strikten Trennung von Inhalt und Layout widerspricht.

[Nina]

was nicht wirklich schade ist, da es der strikten Trennung von Inhalt und Layout widerspricht.

Ich sehe das bei einem CMS etwas anders. Zumindest das CSS das im Header durch Einstellungen von Seitenlayouts kommt (also z. B. Angaben für die linke/rechte Spalte) ist bei einem CMS kein Problem.

Der Anspruch zwischen der strikten Trennung ist ja, dass sich die Sache dauerhaft und seitenübergreifend sauber updaten lässt. Bei statischen Seiten wären daher solche Anweisungen problematisch, weil ich dann wirklich jede Seite in einem Editor öffnen und bearbeiten müsste. Bei einem CMS hingegen ist das vermutlich ein einziges Seitenlayout in dem ich eine Anweisung umschreibe, die sich dann automatisiert für alle Seiten auswirkt die dieses Seitenlayout haben.

Allerdings spreche ich jetzt nur von dem Fall. Wenn natürlich Leute hergehen und mit dem Rich Text Editor Inline-CSS produzieren, oder die Abstände einzelner Inhaltselemente direkt im Element definieren, dann ist das durchaus problematisch. Allerdings aber eben auch nichts, das durch die Variable „$this->framework“ verursacht würde, sondern durch den Editor (und den Admin, der ihm das durchgehen lässt ).

[wotank]

Der Anspruch zwischen der strikten Trennung ist ja, dass sich die Sache dauerhaft und seitenübergreifend sauber updaten lässt. Bei einem CMS hingegen ist das vermutlich ein einziges Seitenlayout in dem ich eine Anweisung umschreibe, die sich dann automatisiert für alle Seiten auswirkt die dieses Seitenlayout haben.

Für mich besteht der Anspruch auch in der Übersichtlichkeit. Bei Anweisungen, die im head hinterlegt sind muss ich dann auch noch da gucken und nicht nur bei den CSS-Dateien.
Okay, Contao ist ein seitenbasierendes CMS, da ist diese Lösung wohl die Einfachste. Eine bessere Alternative kann ich auch grad nicht aus dem Ärmel schütteln.

Eigentlich bereiten mir die contao.css und die iefixes.css mehr Kopfschmerzen:
Da stehen Anweisungen drin die einerseits Fehler verhindern sollen, andererseits aber die Quelle von Fehlern sein können.

Da bietet nur noch die herunterladbare basic.css größeres Ungemach, weil da teilweise ein solcher Schmarrn drinsteht, das ich nur noch fassungslos den Kopf schütteln kann.
Schlimm ist da vor allem das es dann von Menschen übernommen wird, die sich bei CSS nicht so gut auskennen.

edit. den Schmarrn sollte ich wohl auch belegen:

body {
    font-size:12px;
}
pre,code {
    font-size:12px;
}
h1 {
    font-size:22px;
}
h2 {
    font-size:20px;
}
h3 {
    font-size:18px;
} 

Das sorgt dafür das die IE-eigene Funktion (auch im IE8 nicht!) zur Textvergrößerung schlichtweg nicht funktioniert ( Seite - Textgröße ). Es bleibt nur der Seitenzoom.
Das wollen aber die allermeisten nicht, weil man da ruckzuck horizontal scrollen muss, um zu lesen. Besonders bei notebooks/netbooks ist das schnell der Fall.

Es ist mir absolut unverständlich warum es offensichtlich nicht möglich ist px z.B. gegen % auszutauschen.

[schman]

Hi wotank,
ich bin ja absolut kein CSS Guru aber nachdem ich den Artikel von praegnanz gelesen hatte (und ich der Meinung bin das er schon Ahnung hat) habe ich angefangen auch pixel zu verwenden.

Meine Frage, stimmt das was im Artikel steht nicht?

[wotank]

Moin Manuel,

ich bin ja absolut kein CSS Guru

ich sicher auch nicht!

aber nachdem ich den Artikel von praegnanz gelesen hatte (und ich der Meinung bin das er schon Ahnung hat) habe ich angefangen auch pixel zu verwenden.

Meine Frage, stimmt das was im Artikel steht nicht?

ja diesen Artikel habe ich auch gelesen.
Da weiss ich nicht recht ob ich lachen oder weinen soll.
Pseudofa..... Du... oder einfach ignora..... Gela....., mit dieser Meinung stehe ich nicht alleine da.
Viele die ich kenne haben einfach nur fassungslos mit dem Kopf geschüttelt.

Zitat von praegnanz.de:
Der IE 6 ist kein wirklich maßgeblicher Browser mehr, und wer ihn heute noch nutzt, ist selber Schuld. Diejenigen, die im IE 6 die Funktion zur Schriftvergrößerung gefunden haben, sind sicherlich auch in der Lage gewesen, den Update-Button zu finden.

Das ist an Arroganz/Ignoranz wohl kaum zu überbieten.
Das sind Machtphantasien die vor Monitoren in einsamen Räumen entstehen.
Welcher Browser installiert wird entscheidet immer noch der User und nicht der Webdesigner.

Zitat von praegnanz.de:
Heute arbeiten alle modernen Browser mit Seitenzoom, vergrößern also alle Seitenelemente nach Belieben.

Das wollen aber die allermeisten nicht, weil man da ruckzuck horizontal scrollen muss, um zu lesen. Besonders bei notebooks/netbooks ist das schnell der Fall.

Ich liebe selfrecycling.

Ich hab hier mal nen kleinen Testcase zusammengebastelt, wo ich die basic.css eingefügt und um ein paar Angaben ergänzt habe:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Schriftvergrößerung</title>
<style type="text/css">

body,div,h1,h2,h3,h4,h5,h6,p,blockquote,pre,code,ol,ul,li,dl,dt,dd,table,th,td,form,fieldset,legend,input,textarea {
    margin:0;
    padding:0;
}

table {
    border-collapse:collapse;
    border-spacing:0;
}
caption,th,td {
    text-align:left;
    vertical-align:top;
}
abbr,acronym {
    font-variant:normal;
    border-bottom:1px dotted #666;
    cursor:help;
}
blockquote,q {
    quotes:none;
}
fieldset,img {
    border:0;
}
li {
    list-style-type:none;
}
sup {
    vertical-align:text-top;
}
sub {
    vertical-align:text-bottom;
}
del {
    text-decoration:line-through;
}
ins {
    text-decoration:none;
}
a {
    color:#00f;
}
:focus {
    outline:0;
}

/* Font settings */
body {
    font-family:"Lucida Grande","Lucida Sans Unicode",Verdana,sans-serif;
    font-size:12px;
    color:#000;
    background:#f1f1f1;
}
input,button,textarea,select {
    font-family:inherit;
    font-size:99%;
    font-weight:inherit;
}
pre,code {
    font-family:"Lucida Console",Monaco,monospace;
    font-size:12px;
}
h1,h2,h3,h4,h5,h6 {
    font-size:100%;
    font-weight:normal;
}
h1 {
    font-size:22px;
}
h2 {
    font-size:20px;
}
h3 {
    font-size:18px;
}
table {
    font-size:inherit;
}
caption,th {
    font-weight:bold;
}


h1,h2,h3,h4,h5,h6 {
    margin-top:1em;
}
h1,h2,h3,h4,h5,h6,p,pre,blockquote,table,ol,ul,form {
    margin-bottom:12px; 
}
#umhang  {
    width:600px;
    margin:2em auto;
    background:#dcdcdc;
}
</style>
</head>

<body>
        
<div id="umhang">

<div id="box>
   <ul>
       <li><strong>Startseite</strong></li>
       <li><a href="#">Leistungen</a></li>
       <li><a href="#">Galerie</a></li>
       <li><a href="#">Kontakt</a></li>       
   </ul> 
    <p>Das erste, was ich sagen möchte, ist ein herzliches Wort des Dankes an meine 
    Freunde im Evangelischen Arbeitskreis, 
    die in diesen Jahrzehnten - in diesem Jahr begehen wir noch ein 
    wichtiges Erinnerungsdatum an Hermann Ehlers - eine grossartige
    Arbeit für unsere Sache geleistet haben.</p>
</div>   
    
</div>

</body>
</html> 

Einfach mal im IE8 öffnen und versuchen den Text mit der entspr. IE-Funktion zu vergrößern.
Was passiert? Genau, nämlich nix!

Es geht hier nicht um die Rettung der Welt, sondern um eine winzige Kleinigkeit, um die Zugänglichkeit und Usability für eine Minderheit zu verbessern.
Warum man das nicht machen kann erschließt sich mir überhaupt nicht.
Imho gibt es kein vernünftiges Argument was dagegen spricht die Schriftgröße in em oder % anzugeben.
Ein Layout sollte das aushalten, ansonsten sollte man vielleicht drüber nachdenken, ob es flexibel genug ist.

[schman]

Das ist an Arroganz/Ignoranz wohl kaum zu überbieten.
Das sind Machtphantasien die vor Monitoren in einsamen Räumen entstehen.
Welcher Browser installiert wird entscheidet immer noch der User und nicht der Webdesigner.

Ok das mag sein aber ganz ehrlich, ich persönlich schau da gar nicht mehr draum, mittlerweile ist es eine Kunst den IE6 überhaupt noch zu installieren . Natürlich mache ich keine großen Seite bei denen große Firmen etc. zur Zielgruppe gehört. Darum bin ich jetzt auch mal so arrogant und behaupte das es "egal" ist.

Einfach mal im IE8 öffnen und versuchen den Text mit der entspr. IE-Funktion zu vergrößern.
Was passiert? Genau, nämlich nix!

Auch da hast du Recht, hast du schon mal deswegen ein Ticket angelegt? Normalerweise reagiert Leo da eh sehr positiv drauf.

[wotank]

Ok das mag sein aber ganz ehrlich, ich persönlich schau da gar nicht mehr draum, mittlerweile ist es eine Kunst den IE6 überhaupt noch zu installieren . Natürlich mache ich keine großen Seite bei denen große Firmen etc. zur Zielgruppe gehört. Darum bin ich jetzt auch mal so arrogant und behaupte das es "egal" ist.

da haste auch wieder recht.
Große Firmen mach ich auch nicht, weshalb es wohl egal wäre.

Naja, ich hab zumindest den Ehrgeiz das es auch im IE6 funktionieren sollte.

Auch da hast du Recht, hast du schon mal deswegen ein Ticket angelegt? Normalerweise reagiert Leo da eh sehr positiv drauf.

nein, mit den Tickets weiss ich nicht so recht.
Erst klappte es mit der Anmeldung nicht, dann sollte ich mir ne Software runterladen und installieren, damit das klappt. Das hab ich nicht so richtig verstanden.
Oder ich hab da was in den falschen Hals gekriegt, was auch gut möglich ist.
In dem Falle wäre ich für eine Aufklärung dankbar.

[bubblez]

@wotank
Einfach auf http://dev.contao.org/projects/typolight registrieren, dann kannst du da Tickets anlegen.

[joad]

HI

Wenn du in deinem Template fe_*.tpl die Variable „$this->framework“ rausnimmst, verschwinden die beiden Dateien. Allerdings auch das Inline-CSS.

Sebastian

Danke! Jetzt ist es sauber, freue mich sehr :-)

Was die Thematik von Standard-CSS-Einstellungen angeht kann ich mich natürlich nicht in der Tiefe wie Ihre es tut äußern, generell finde ich jedoch gibt es schon zu viele CMS-Systeme die zum Framework und den Verwaltungsmechaniken irgendwelche Formatierungen / Grundvorlagen mitliefern. Bei Contao war ich positiv überrascht das ich mir fix ein paar Platzhalter setzen kann und damit schon ein Seitentemplate geschaffen habe das "nur noch" Fragmente benötigt. Formatierungen und zu eng gefasste Layoutbedingungen gibts schon genügend, ich nenne mal Sharepoint (schauder).

[wotank]

Auch da hast du Recht, hast du schon mal deswegen ein Ticket angelegt? Normalerweise reagiert Leo da eh sehr positiv drauf.

Ticket ist angelegt!
Jetzt bin ich ja mal gespannt.

[wotank]

Ticket ist angelegt!
Jetzt bin ich ja mal gespannt.

Mein Ticket war ruckzuck invalid.

Hab ich da was falsch gemacht oder gibt es das Ticket schon einmal??
Das ist mir völlig unverständlich, weil es ja so leicht nachzuvollziehen ist (auch in der Online-Demo!) und fast noch leichter zu ändern ist.

Ist es vielleicht nicht gewünscht das sich IE-Nutzer den Text vergrößern können??
Kann ich mir aber eigentlich nicht vorstellen, weil sich Contao die Barrierefreiheit ja irgendwie auf die Fahnen geschrieben hat.

Wenn es das Ticket schon länger gibt stellst sich die Frage warum das dann noch nicht umgesetzt wurde?

Hat jemand eine Idee warum das Ticket invalid ist?
Für eine Aufklärung wäre ich sehr dankbar.

[bubblez]

..., weil sich Contao die Barrierefreiheit ja irgendwie auf die Fahnen geschrieben hat.

Dacht ich auch schon! Allerdings wirds m.M. nicht immr konsequent umgesetzt.

Hab ich da was falsch gemacht ...

Ich versteh die Ticket-Beantwortungs-Philosophie von leo auch nicht. Wenn ihm was daran liegt gute Software zu schreiben und die Community ernst nehem würde, dann könnte er min. einen kurzen Grund angeben, warum das Ticket invalid sein sollte!

[wotank]

Kann ich mir aber eigentlich nicht vorstellen, weil sich Contao die Barrierefreiheit ja irgendwie auf die Fahnen geschrieben hat.

Dacht ich auch schon! Allerdings wirds m.M. nicht immr konsequent umgesetzt.

Ja da besteht sicher noch Optimierungsbedarf. das kann natürlich noch werden.

Z.B. ist bei jeder navi ein Link dabei, mit dem man die navi überspringen kann, aber einen Link wo man zurückspringen kann habe ich noch nicht entdeckt.
Für Screenreaderuser sicher eine suboptimale Lösung.

Eine konsequente Vorgehensweise, vor allem für Besucher, die auf einen Screenreader angewiesen sind, wäre es wenn direkt am Anfang und am Ende jeder Seite Skiplinks mit ausgegeben werden.
Nicht mehr als ein bis drei wg. der Übersicht.
Oben jeweils zur navi, zum Inhalt, zur nebennavi und unten jeweils die Rücksprünge zur navi, zum Anfang Inhalt, zur nebennavi.
Dazu sollte für die Durchtabber noch eine Klasse .skiplinktabs ausgegeben werden, damit auch Sie die Sprungnavi beim Durchtabben sichtbar machen können.

Das Ausgeben solcher Skiplinks ist aber imho nicht so einfach umzusetzen, da die Anzahl varieren kann und der optimale Ort (direkt nach der h1-Hauptüberschrift im header, damit der Screenreaderuser so die Titelüberschrift der Seite vorgelesen bekommt, bevor er springen kann) auch nicht so einfach umzusetzen ist, denke ich.

Naja, falls da kein weiteres Feedback vom Entwickler kommt wird das mein erstes und letztes Ticket gewesen, was ich geschrieben habe.
Das wäre schade, weil ich immer interessiert bin etwas zu verbessern.

[christian]

Hat jemand eine Idee warum das Ticket invalid ist?
Für eine Aufklärung wäre ich sehr dankbar.

Die basic.css kannst Du verwenden, musst es aber nicht. Sie ist nicht automatischer Bestandteil des Frameworks, sondern Bestandteil des (mitgelieferten) Beispiel-Templates "Music Academy".

Von daher ist klar, dass Leo das Ticket auf invalid setzt - es hat nichts mit dem System an sich zu tun.

Dass Du keine spezielle Erläuterung bekommst, ist soweit normal. Wenn man als Entwickler zu jedem Ticket etwas schreiben soll, kommt man irgendwann nicht mehr zu seinen eigentlichen Aufgaben. Dafür gibt's doch das Forum: Hier kann nach Herzenslust darüber diskutiert werden, ob der Ticket-Inhalt denn sinnvoll war oder nicht. Das das ggf. zunächst nicht so freundlich rüberkommt, ist klar - aber bestimmt nicht böse gemeint.

Grüße,

Christian

[Nina]

Ich schließe mich Christians Ausführung an.

Was die Sache mit Sprunglinks, Barrierefreiheit etc. angeht: Das haben wir mehrfach im Forum diskutiert und dabei erläutert, warum eben z. B. nicht standardmäßig vom System Sprunglinks am Anfang zu Inhalt, etc. ausgegeben werden, sondern wir in dem Fall den Webdesigner/Admin in der Pflicht sehen, das selbst korrekt anzulegen.

Auch wenn euch manche Entscheidung auf den ersten Blick falsch erscheinen mag, so kann ich euch versichern, dass wir uns als Team immer Gedanken machen und eine Logik hinter unseren Entscheidungen steht. Wenn es möglich ist, erläutern wir die auch, aber man kann nicht alles immer und immer wieder erklären sondern muss auch davon ausgehen können, dass die Nutzer recherchieren, ob es das Thema vielleicht schon gegeben hat bzw. dass die Nutzer auch ihrerseits versuchen die Zusammenhänge zwischen Entscheidungen zu verstehen.

Was das Thema Barrierefreiheit an sich angeht, möchte ich euch nur einen allgemeinen Tipp geben: Geht bitte nicht pauschal davon aus, dass eure Meinung zu Barrierefreiheit immer zu 100% stimmt und auf jedes Projekt automatisiert passt. Ich kann nur aus eigener Erfahrung sagen, dass man zur Barrierefreiheit ständig dazu lernt und auch als Profi immer wieder mal in Situationen kommt, wo man eine Meinung die man bisher vertreten hat, revidiert, weil man Neues dazu lernt. UND: Frage z. B. zwei Blinde zu einer Sache und du wirst 3 Meinungen erhalten, wobei jeder der Nutzer ganz vehement der Meinung ist, dass seine Sichtweise die richtige ist. So ist das halt einfach mit Menschen und ihrem Nutzerverhalten.

[wotank]

Tach Christian und Nina,

danke!
Jetzt konnte ich es besser verstehen.

Da das nicht zum System von Conato gehört und deshalb invalid geschaltet wurde, ist nachvollziehbar.
Auch das man auf jedes Ticket ausführlich antworten ist in Ordnung.

Das es mit den Skiplinks nicht befriedigend zu lösen ist habe ich schon fast vermutet.

Trotzdem bleibt die Frage ob man die basic.css nicht im Lichte der Erkenntnisse einfach anpassen kann?
Viele die die basic.css verwenden und noch nicht so versiert sind wissen doch meist gar nicht das damit der Textzoom im IE nicht mehr funktioniert.

[Nina]

Ich denke, dass es vor allem ein Zeitproblem ist. Es gibt derzeit so viel wichtigeres bei der Contao-Entwicklung das dringend gemacht werden muss.

[wotank]

Ich denke, dass es vor allem ein Zeitproblem ist. Es gibt derzeit so viel wichtigeres bei der Contao-Entwicklung das dringend gemacht werden muss.

kein Problem!

/**
 * Contao Open Source CMS
 * Copyright (C) 2005-2010 Leo Feyer
 *
 * Formerly known as TYPOlight Open Source CMS.
 *
 * This program is free software: you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation, either
 * version 3 of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 * 
 * You should have received a copy of the GNU Lesser General Public
 * License along with this program. If not, please visit the Free
 * Software Foundation website at <http://www.gnu.org/licenses/>.
 *
 * PHP version 5
 * @copyright  Leo Feyer 2005-2010
 * @author     Leo Feyer <http://www.contao.org>
 * @license    LGPL
 * @version    1.0
 */

/* Reset margins */
body,div,h1,h2,h3,h4,h5,h6,p,blockquote,pre,code,ol,ul,li,dl,dt,dd,table,th,td,form,fieldset,legend,input,textarea {
    margin:0;
    padding:0;
}

/* Format basic elements */
table {
    border-collapse:collapse;
    border-spacing:0;
}
caption,th,td {
    text-align:left;
    vertical-align:top;
}
abbr,acronym {
    font-variant:normal;
    border-bottom:1px dotted #666;
    cursor:help;
}
blockquote,q {
    quotes:none;
}
fieldset,img {
    border:0;
}
li {
    list-style-type:none;
}
sup {
    vertical-align:text-top;
}
sub {
    vertical-align:text-bottom;
}
del {
    text-decoration:line-through;
}
ins {
    text-decoration:none;
}
a {
    color:#00f;
}
:focus {
    outline:0;
}

/* Font settings */
body {
    font-family:"Lucida Grande","Lucida Sans Unicode",Verdana,sans-serif;
    font-size:80%;
    color:#000;
}
input,button,textarea,select {
    font-family:inherit;
    font-size:99%;
    font-weight:inherit;
}
pre,code {
    font-family:"Lucida Console",Monaco,monospace;
    font-size:80%;
}
h1,h2,h3,h4,h5,h6 {
    font-size:100%;
    font-weight:normal;
}
h1 {
    font-size:150%;
}
h2 {
    font-size:130%;
}
h3 {
    font-size:115%;
}
table {
    font-size:inherit;
}
caption,th {
    font-weight:bold;
}

/* Default margins */
h1,h2,h3,h4,h5,h6 {
    margin-top:1em;
}
h1,h2,h3,h4,h5,h6,p,pre,blockquote,table,ol,ul,form {
    margin-bottom:12px; /* Should match the font size */
} 

habs einfach geändert und auch als .tpl hochgeladen.
Muss nur noch umbenannt und an der richtigen Stelle abgespeichert werden.

[about:blank]

Was spricht eigentlich gegen die Integration eines bewährten reset.css wie z. B. YUI?

[pmmueller]

Was spricht eigentlich gegen die Integration eines bewährten reset.css wie z. B. YUI?

Überhaupt gar nichts. Einfach machen.

Die basic.css zum Downloaden ist doch nur ein Angebot. Jeder kann sein eigenes Reset-Stylesheet einbinden oder die basic.css abändern wie er lustig ist.

px oder nicht px
Ich bin ja nu selbst eher ziemlich CSS-lastig, aber ich verstehe ehrlich gesagt diesen Aufstand um Pixel vs. Nicht-Pixel für die Schriftartdefinition nicht ganz. Wenn mir das wirklich wichtig ist, dann definiere ich das doch in meinem Stylesheet einfach anders. Dazu gibt es die Kaskade.

Zur Trennung von Inhalt und Gestaltung: Inline-Styles in jeglicher Form (auch in den Elementen selbst) sind ein völlig legitimer Bestandteil der Kaskade und weder schlecht noch sollten sie verpönt sein.

CSS im CMS
Wenn ich alleiniger Autor einer Site bin, kann ich sie natürlich weitgehend vermeiden, aber in einem komplexeren Entstehungsprozess, in dem nicht ein Autor die komplette Seite erstellt, ist es im Editor eine völlig legitime Möglichkeit für mich als Redakteur, die Ausnahme von der CSS-Regel zu definieren.

Fazit
Nicht drüber aufregen , dass Contao irgendwo ein px zuviel einsetzt. Lieber drüber freuen, dass das System uns problemlos erlaubt, das unerwünschte px zu entfernen

[pmmueller]

... habs einfach geändert und auch als .tpl hochgeladen.
Muss nur noch umbenannt und an der richtigen Stelle abgespeichert werden.

Nur aus Neugier Warum speicherst du ein Stylesheet als .tpl? Wo willst du es einbinden?

Den Kommentar am Anfang solltest du vielleicht noch anpassen, denn Leo ist ja nicht mehr wirklich der Autor. Oder zumindest reinschreiben, dass du es geändert hast. Und was.

[wotank]

px oder nicht px
Ich bin ja nu selbst eher ziemlich CSS-lastig, aber ich verstehe ehrlich gesagt diesen Aufstand um Pixel vs. Nicht-Pixel für die Schriftartdefinition nicht ganz. Wenn mir das wirklich wichtig ist, dann definiere ich das doch in meinem Stylesheet einfach anders. Dazu gibt es die Kaskade.

Viele wissen gar nicht das die text-size-Funktion des IE nicht mehr funktioniert, wenn Pixel für die Schriftgröße angegeben.
Es gibt ja auch viele Hobbybastler, die Contao für ihre Website hernehmen.
Diese Menschen wollen sich ja auch nicht so mit der Materie befassen.

Klar kann man das ändern...wenn man es denn weiß.

Paradoxerweise habe ich persönlich die Erfahrung gemacht das Amateure eher geneigt sind das zu ändern, wenn man sie darauf aufmerksam macht.
Profis begegnen dem Hinweis fast immer mit Ignoranz.

Vielleicht liegt es an Gerrits unsäglichem und fachlich imho vollkommen schwachsinnigen Artikel, den sich viele Profis zum Vorbild nehmen.
Das ist aber eigentlich auch unverständlich, weil man das Ganze mit einem vollkommen simplen Testcase überprüfen kann.

Mit diesem Kommentar:

Ich denke, dass es vor allem ein Zeitproblem ist. Es gibt derzeit so viel wichtigeres bei der Contao-Entwicklung das dringend gemacht werden muss.

ist für mich jedenfalls klar, das offensichtlich kein Interesse daran besteht, da was zu ändern.

Zur Trennung von Inhalt und Gestaltung: Inline-Styles in jeglicher Form (auch in den Elementen selbst) sind ein völlig legitimer Bestandteil der Kaskade und weder schlecht noch sollten sie verpönt sein.

Oh mann Peter, das ist jetzt nicht dein Ernst oder?

Klar ist das legitim inline-Styles zu verwenden, es wäre ja auch vollkommen legitim wieder zum Tabellendesign zurückzukehren, weil die ja auch ein legitimer Bestandteil der Kaskade sind.

Dein Posting transportiert doch irgendwie die Aussage: "Hey Leute, nehmt ruhig Inline-Styles, wenn euch grad danach ist. Ist völlig legitim!"

Das lesen Menschen, die sich noch nicht so gut auskennen und denken, das die geforderte Trennung von Inhalt und Gestaltung allenfalls eine lockere Empfehlung ist, die man gerne auch ignorieren kann.

Fazit
Nicht drüber aufregen , dass Contao irgendwo ein px zuviel einsetzt. Lieber drüber freuen, dass das System uns problemlos erlaubt, das unerwünschte px zu entfernen

Das kann ich in jedem CMS was ich kenne problemlos anpassen.

Contao nennt sich selbst Barrierefreies Open Source Content Management System.
Für mich klaffen da Anspruch und Wirklichkeit leider auseinander, vor allem da für mich kein besonderer Wille erkennbar ist, wirklich winzige Verbesserungen hinsichtlich der barriereärmeren Benutzbarkeit zu ändern.

Warum man in der basic.css den Rahmen für die Durchtabber entfernt hat, davon will ich lieber nicht auch noch anfangen:

:focus {
    outline:0;
} 

[wotank]

Nur aus Neugier Warum speicherst du ein Stylesheet als .tpl? Wo willst du es einbinden?

weil ich hier keine css-Datei hochladen kann.

Den Kommentar am Anfang solltest du vielleicht noch anpassen, denn Leo ist ja nicht mehr wirklich der Autor. Oder zumindest reinschreiben, dass du es geändert hast. Und was.

Ich habe es deshalb so gelassen, weil ich es möglichst einfach halten wollte die basic.css auszutauschen und an die entsprechende Stelle hochzuladen.

[pmmueller]

Dein Posting transportiert doch irgendwie die Aussage: [I]"Hey Leute, nehmt ruhig Inline-Styles, wenn euch grad danach ist. Ist völlig legitim!

Okay, das sollte es nicht

Das Posting ist mehr so im Sinne von "Hey Leute, nehmt ruhig Inline-Styles, wenn es sinnvoll ist. Ist völlig legitim!" gemeint.

Die von dir eingesetzten 80% sind übrigens auch nicht unbedingt soo ideal, denn von 16px ausgehend gibt das 12.8px und das muss gerundet werden. 81.25% gibt genau 13px, ebenso wie das ganz einfache font-size: small.

[pmmueller]

Warum man in der basic.css den Rahmen für die Durchtabber entfernt hat, davon will ich lieber nicht auch noch anfangen:

:focus {
    outline:0;
} 

Da hast du Recht. Das Ding gehört da wirklich nicht rein, und auch mit den px-Angaben liegst du natürlich nicht falsch.

Eigentlich wehre ich mich glaube ich nur dagegen, Contao auf ein paar nicht ganz schlüssige CSS-Details zu reduzieren, die man noch dazu sehr leicht ändern kann.

[wotank]

Eigentlich wehre ich mich glaube ich nur dagegen, Contao auf ein paar nicht ganz schlüssige CSS-Details zu reduzieren, die man noch dazu sehr leicht ändern kann.

oh, da bin ich wohl falsch rübergekommen.

Natürlich will ich Contao nicht auf ein paar Details reduzieren.
Wie ich schon bei meiner Contao-Kritik im XHTML-Forum schrieb:

Fazit:
Contao hat wie jedes CMS Stärken und Schwächen.
Trotz Kritik gefällt es mir nach wie vor.

Wenn Contao nicht in Frage käme, oder ich das CMS nicht mögen würde, hätte ich mir die Mühe suboptimale Dinge anzusprechen gar nicht erst gemacht.

Da es mir aber nach wie vor gefällt bin ich an kontroversen und konstruktiven Diskussionen interessiert, denn nur so lassen sich imho Dinge im Laufe der Zeit nachhaltig verbessern.
Das trifft auch auf Dinge zu die irgendwann mal gemacht wurden und die nie mehr hinterfragt werden, ob sie beim gegenwärtigen Entwicklungsstand noch Sinn machen.

[pmmueller]

... wie ich schon bei meiner Contao-Kritik im XHTML-Forum schrieb...

wotank = hubspe = Klaus = klassische Schwarzweißfotografie?

Ich komme mit diesen ganzen Foren-Kürzeln durcheinander

[wotank]

wotank = hubspe = Klaus = klassische Schwarzweißfotografie?

Ich komme mit diesen ganzen Foren-Kürzeln durcheinander

sorry Peter!

Meine große Klappe idendifiziert man i.d.R. ziemlich schnell und wenn ich hundert Pseudonyme wähle. Und verstellen....klappt irgendwie nicht