Vermeiden von !important ?

[botl1k3]

Hallo,

Frage steht ja schon im Titel: ist es sinnvoll, !important so oft wie möglich zu vermeiden? Gehört es zu schlechtem Stil?

Mal ein einfaches beispiel:

#mainheader ul {  
  float: right;  
  padding-right: 28px;  
}  
#mainheader ul li {  
  float: left;  
  padding-left: 8px;  
  padding-right: 8px;  
  border-left: 2px solid black;  
}  
#mainheader_first {  
  border: none !important;  
}

Eine Navigationsleiste. Das erste li soll keinen border erhalten und bekommst deswegen die id mainheader_first. Wie würdet ihr soetwas schreiben?
Ist vielleicht eine komische Frage, aber mit gefällt dieses !important an einigen Stellen meines CSS nicht :D

greetz

[Christoph Schnauß]

hallo,

ist es sinnvoll, !important so oft wie möglich zu vermeiden?

Ja.

Gehört es zu schlechtem Stil?

Nein.

Mal ein einfaches beispiel:
[...}
Das erste li soll keinen border erhalten

Den bekommt es aber.

und bekommst deswegen die id mainheader_first

Womit die Anweisung zwar überschrieben und "zurückkorrigiert" scheint, du gibts aber zu erkennen, daß du es damit nicht so ernst meinst.

Wie würdet ihr soetwas schreiben?

Was schreiben? Daß das erste Listenelement keinen Rand, die anderen alle aber doch einen bekommen? Nunja ... jedenfalls anders als du. Das erste bekäme eine Klassennamen, und die CSS würde _ohne_ "!important" für diesen Klassennamen festlegen, daß alles, was damit benannt wird, eben rahmenlos zu sein hat. Fertig.

mit gefällt dieses !important an einigen Stellen meines CSS nicht :D

Warum setzt du es dann ein?

Grüße aus Berlin

Christoph S.

[MudGuard]

Hi,

#mainheader ul li {

specificity: 0102  (kein style-Attribut, 1 id, kein Attribut-/Pseudoklassen-Selektor, 2 Elementselektoren)

#mainheader_first {

specificity: 0100  (kein style-Attribut, 1 id, kein Attribut-/Pseudoklassen-Selektor, kein Elementselektor)

==> das erste border gewinnt (wenn !important nicht da wäre).

Eine Navigationsleiste. Das erste li soll keinen border erhalten und bekommst deswegen die id mainheader_first.

non sequitur.

Das erste li ist das erste Kind des ul, also per

#mainheader ul li:first-child {

selektierbar.
Specificity: 0112 (kein style-Attribut, 1 id, kein Attribut-/Pseudoklassen-Selektor, 2 Elementselektoren)

0112 ist höher als 0102 ==> gewinnt im Zweifelsfall.

cu,
Andreas

[Cheatah]

Hi,

Frage steht ja schon im Titel: ist es sinnvoll, !important so oft wie möglich zu vermeiden? Gehört es zu schlechtem Stil?

die Verwendung von !important ist absolut legitim - sofern sie für Deklarationen verwendet wird, die "important" sind, und nicht als "override". Faustregel: Wenn Du nur eine einzige CSS-Regel hättest und _trotzdem_ !important einsetzen möchtest, ist es richtig.

Eine Navigationsleiste. Das erste li soll keinen border erhalten und bekommst deswegen die id mainheader_first. Wie würdet ihr soetwas schreiben?

#mainheader ul li:first-child (bzw. #mainheader ul li.first, wenn auch der IE in den Genuss dieser Styles kommen soll).

Cheatah

[Der Martin]

Hi Cheatah,

die Verwendung von !important ist absolut legitim - sofern sie für Deklarationen verwendet wird, die "important" sind, und nicht als "override".

das sehe ich anders.
Innerhalb des eigenen CSS-Codes kann ich normalerweise über die Spezifizität und Reihenfolge der Selektoren bestimmen, wer bei mehreren Möglichkeiten "gewinnt". Da sehe ich also eigentlich keinen Grund, !important einzusetzen (habe ich auch so noch nie verwendet).

Dagegen halte ich ein User-Stylesheet, das ja ganz bewusst Vorgaben aus dem Autoren-Stylesheet überschreiben soll, für die ideale Anwendung von !important. Dort kann ich es sinnvoll einsetzen - und zwar gerade als "override".

Faustregel: Wenn Du nur eine einzige CSS-Regel hättest und _trotzdem_ !important einsetzen möchtest, ist es richtig.

Aber sinnlos. ;-)

So long,
 Martin

[Cheatah]

Hi,

Dagegen halte ich ein User-Stylesheet, das ja ganz bewusst Vorgaben aus dem Autoren-Stylesheet überschreiben soll, für die ideale Anwendung von !important. Dort kann ich es sinnvoll einsetzen - und zwar gerade als "override".

nun ja, dazu haben die Stylesheets ja eigentlich auch eine Reihenfolge. Aber im Prinzip muss ich Dir hier Recht geben; die meisten !important habe ich bisher in meinen User-Stylesheets verwendet, und zwar tatsächlich als override. Das ändert aber nichts daran, dass sie dazu nicht da sind ;-)

Cheatah

[ChrisB]

Hi,

Aber im Prinzip muss ich Dir hier Recht geben; die meisten !important habe ich bisher in meinen User-Stylesheets verwendet, und zwar tatsächlich als override. Das ändert aber nichts daran, dass sie dazu nicht da sind ;-)

Wozu sind sie deiner Meinung nach dann da?

Die CSS 2.1 Spezifikation fuehrt zumindest genau dieses Szenario, User- kontra Author-Stylesheet, als Einsatzzweck an.

MfG ChrisB

[botl1k3]

Hi,

danke, ich schreibe es jetzt so: #mainheader ul li.first
Kleine Frage noch: Was hat es mit dieser schreibweise auf sich: li#mainheader ul

gibt es da unterschiede zu #mainheader ul li?

greetz und danke nochmal!

[MudGuard]

Hi,

Kleine Frage noch: Was hat es mit dieser schreibweise auf sich: li#mainheader ul

Das selektiert ul-Elemente innerhalb des li-Elements mit der id mainheader

gibt es da unterschiede zu #mainheader ul li?

Das selektiert li-Elemente innerhalb eines ul-Elements innerhalb des Elements mit der id mainheader.

cu,
Andreas

[Jonathan]

Hallo botl1k3,

Kleine Frage noch: Was hat es mit dieser schreibweise auf sich: li#mainheader ul

gibt es da unterschiede zu #mainheader ul li?

Wenn du den Unterschied zwichen

li#mainheader

und

#mainheader

meinst, der einzige Unterschied ist eben, dass das mainheader-Element im ersten Fall ein li sein muss.

Die Schreibweise wäre dann sinnvoll, wenn eine id auf verschiedenen Seiten mehrere Element-typen zugeordnet wird, was aber eher unsinnig wäre, oder wenn ich der Übersicht wegen im CSS auf den Elementtyp hinweisen will.

Jonathan

[botl1k3]

Hi,

hab jetzt mein CSS fast vollständig ohne !important.
Aber ganz ohne geht es wohl doch nicht, denn ich habe anscheinend mit einem anderem Verhalten der Selektoren gerechnet:

#eineid tr td, bewirkt nicht nur, dass:

<table id="eineid">  
  <tr>  
    <td>diese td</td>  
  </tr>  
</table>

davon betroffen ist, sondern auch

<table id="eineid">  
  <tr>  
    <td>  
      <table>  
        <tr>  
          <td class="bitteaendern">diese td</td>  
        </tr>  
      </table>  
    </td>  
  </tr>  
</table>

Das heißt, wenn ich eine Eigenschaft wie in diesem Beispiel für eine Untertabellen-td verändern möchte, muss ich !important benutzen?!

[Sven Rautenberg]

Moin!

Aber ganz ohne geht es wohl doch nicht, denn ich habe anscheinend mit einem anderem Verhalten der Selektoren gerechnet:

Vermutlich.

#eineid tr td, bewirkt nicht nur, dass:

Das selektiert jegliches TD, welches sich innerhalb eines TR befindet, welches sich wiederum innerhalb des Elements mit ID "eineid" befindet.

Das trifft für deine beiden TD-Konstrukte fraglos zu.

Das heißt, wenn ich eine Eigenschaft wie in diesem Beispiel für eine Untertabellen-td verändern möchte, muss ich !important benutzen?!

Nein, einen passenderen Selektor:

#eineid table tr td. Das selektiert ein TD in einem TD in einer TABLE, die sich INNERHALB der ID #eineid befindet.

Alternativ wäre auch #eineid tr td td denkbar, und noch weitere hunderttausend Konstruktionen, deren Nutzbarkeit - insbesondere im Hinblick auf z.B. den Kindselektor ">" - im IE aber nicht immer gegeben ist.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Ach ja, ergänzend:

#eineid tr td, bewirkt nicht nur, dass:

Wie dir nicht entgangen sein dürfte, wirken die Formatierungen immer auf das letztgenannte Element eines Selektors, in diesem Falle also einem TD.

Da ein TD grundsätzlich in einem TR zu stehen hat, ist der Selektor "tr td" eigentlich doppelt gemoppelt. Er filtert keine TD heraus, die NICHT in einem TR stehen, weil das alle TD tun müssen.

#eineid td dürfte also genau die gleichen Elemente treffen, wie #eineid tr td.

Die kürzeste Form, aufbauend auf diesem Selektor dann TDs in Subtabellen zu formatieren, wäre #eineid td td. Das findet alle TDs, die sich (beliebige Schachtelungstiefe!) innerhalb von einem TD befinden, gilt also für alle Sub-, Subsub- und X*Sub...-Tabellenzellen.

Der einzige technische Grund, einen Selektor durch offensichtliche Elemente länger zu machen, als er sein müßte, ist die gezielte Erhöhung der Selektor-Spezifität (das ist allerdings ungefähr dasselbe, wie das Hinzufügen von !important).

Und natürlich, um seine Selbsterklärungskraft zu steigern. Längere Selektoren erzählen, insbesondere wenn aussagekräftige IDs und Klassen verwendet werden, von ganz allein, welche Seitenbestandteile da formatiert werden, ohne dass man das noch extra kommentieren muß.

- Sven Rautenberg

[botl1k3]

Hallo,

da hast Du Recht, darauf bin ich dann garnicht mehr gekommen. Ich werde es aber trotzdem nicht so machen, weil ich die id (also das Elternelement von dem ganzen) in ziemlich vielen html-Dokumenten benutze und an sehr vielen Stellen in meinem Stylesheet vorne dran immer "#eineid td.blubb" stehen würde.
Übersichtlich wäre das ganze dann noch weniger.

Also ist es doch sinnvoller, die id einfach in eine Klasse umzuwandeln, selbst wenn sie nur einmal vorkommt. Halte ich persönlich für besser, oder gibts daran etwas auszusetzen?

greetz und danke für die nette Hilfe von euch allen!

[Sven Rautenberg]

Moin!

Hallo,

da hast Du Recht, darauf bin ich dann garnicht mehr gekommen. Ich werde es aber trotzdem nicht so machen, weil ich die id (also das Elternelement von dem ganzen) in ziemlich vielen html-Dokumenten benutze und an sehr vielen Stellen in meinem Stylesheet vorne dran immer "#eineid td.blubb" stehen würde.

Wieso kommst du denn jetzt mit einer Klasse? Hat doch niemand von gesprochen!

Also ist es doch sinnvoller, die id einfach in eine Klasse umzuwandeln, selbst wenn sie nur einmal vorkommt. Halte ich persönlich für besser, oder gibts daran etwas auszusetzen?

Nein. Eine ID ist eine ID und sollte eine bleiben, wenn technisch keine Gründe dagegen sprechen (wie z.B. Mehrfachnutzung)

- Sven Rautenberg

[botl1k3]

Hi,

Wieso kommst du denn jetzt mit einer Klasse? Hat doch niemand von gesprochen!

Das liegt daran, dass mein CSSheet sonst so aussehen würde:

#elternid td {...}
#elternid td... {...}
#elternid td... {...}
#elternid td... {...}
#elternid td... {...}
...
...

so ist das kaum noch übersichtlich, das würde noch viel mehr werden.

Ist es da nicht so übersichtlicher:
.elternid td {...}
.kindclass td... {...}
.kindclass td... {...}
.kindklass td... {...}
?

obwohl es vom Schreibaufwand nicht weniger wird.
Eine andere Möglichkeit wäre es natürlich, im oberem Fall nicht #elternid td zu schreiben, sondern .elterntd und dies jedem td zu geben (sind immer nur 3)..

Was hälst Du für das beste?

greetz

[Sven Rautenberg]

Moin!

Wieso kommst du denn jetzt mit einer Klasse? Hat doch niemand von gesprochen!
Das liegt daran, dass mein CSSheet sonst so aussehen würde:

#elternid td {...}
#elternid td... {...}
#elternid td... {...}
#elternid td... {...}
#elternid td... {...}
...
...

Was bedeuten die Punkte?

so ist das kaum noch übersichtlich, das würde noch viel mehr werden.

Ist es da nicht so übersichtlicher:
.elternid td {...}
.kindclass td... {...}
.kindclass td... {...}
.kindklass td... {...}

Das sieht für mich genauso unübersichtlich aus. Für dich nicht?

Die zweite Frage wäre: Wo setzt du die Kindklasse rein?

Die dritte Frage wäre: Welcher tabellarische Inhalt erfordert denn bloß drei ineinander geschachtelte Tabellenebenen?

Vielleicht solltest du DARAN mal arbeiten - ich habe nicht den Eindruck, dass du die Tabellen sachgemäß einsetzt.

Eine andere Möglichkeit wäre es natürlich, im oberem Fall nicht #elternid td zu schreiben, sondern .elterntd und dies jedem td zu geben (sind immer nur 3)..

Was hälst Du für das beste?

Ich kann gute Lösungen nur geben, wenn ich die Ursprungsaufgabe kenne - und logischerweise auch das zur Aufgabenlösung gedachte HTML, denn CSS geht nun mal nicht frei Hand, sondern orientiert sich immer am HTML, das formatiert werden soll.

- Sven Rautenberg

[Auge]

Hallo

Die dritte Frage wäre: Welcher tabellarische Inhalt erfordert denn bloß drei ineinander geschachtelte Tabellenebenen?

Die Frage stellt sich mir schon seit n Postings.

Vielleicht solltest du DARAN mal arbeiten - ich habe nicht den Eindruck, dass du die Tabellen sachgemäß einsetzt.

Der mMn erste zielführende Ratschlag.

Also botl1k3, schaue dir deinen HTML-Quelltext an und schaue, ob der so aussehen muss, wie er es tut. Du musst nämlich Elemente nicht (um)formatieren, die nicht vorhanden sind.

Tschö, Auge

[botl1k3]

Hallo!

Die dritte Frage wäre: Welcher tabellarische Inhalt erfordert denn bloß drei ineinander geschachtelte Tabellenebenen?

Also, ihr seht das schon richtig, dass wiedereinmal jemand Tabellen ihrem Zweck entfremdet :D
ABER bevor ihr mich jetzt steinigt, lest erst mal warum:

Es geht um eine Website, deren Inhalt zentriert dargestellt wird (soweit kein Problem, das geht auch mit einem div).
Das Problem ist jedoch, dass der content eine feste width hat, und der restliche Hintergrund (der in der Breite dann variabel ist und den rest des füllt) _links und rechts verschieden_ sein soll...
Ich habe lange eine Lösung gesucht, auch hier im Forum einen Thread erstellt, aber keine Lösung gefunden. Darum verwende ich in diesem Fall eine Table.
Ich wage mal zu sagen, dass es dafür keine elegante Lösung mit div-Elementen gibt...

greetz

[Gunnar Bittersmann]

@@botl1k3:

Ich wage mal zu sagen, dass es dafür keine elegante Lösung mit div-Elementen gibt...

Du wagst ganz schön viel.

Den Unterschied zwischen „es gibt keine“ und „ich kenne keine“ kennst du? Es gibt einen.

Live long and prosper,
Gunnar

[botl1k3]

Hi,

Du wagst ganz schön viel.

Das weiß ich :D Wie gesagt, ich habe lange gesucht und das Forum bereits befragt

Es gibt einen.

Dann verrate ihn mir doch bitte!
Ich werde evtl. heute abend mal wieder einen Thread darüber aufmachen, da dieser hier sich ja mit einem anderem Thema befasst.

greetz

[Jonathan]

Hallo botl1k3,

Das heißt, wenn ich eine Eigenschaft wie in diesem Beispiel für eine Untertabellen-td verändern möchte, muss ich !important benutzen?!

Nein.

Du kanst das erste td auch mit

#eineid > tr > td ansprechen, das .bitteaendern mit #eineid > tr > td > table > tr > td (ginge natürlich auch kürzer, nur als Demo)

Da dieses > einige Browser nich können ginge natürlich auch

#eineid td um beide anzusprechen bzw. #eineid td td für das hintere wobei du dann evtl. die Eigenschaften, die nur fürs erste bestimmt sind, wieder aufheben musst.

Jonathan