Frage zu CSS (Attributselektor)

[Forster]

Ich habe folgendes gefunden

[id=id_value] { Stileigenschaften }

Ich bräuchte aber eine Negierung, d.h. id nicht = id_value. Kann man so etwas auch realisieren?

[Matthias Apsel]

Hallo Forster,

[id=id_value] { Stileigenschaften }

Ich bräuchte aber eine Negierung, d.h. id nicht = id_value.

Also alle Elemente, die eine ID besitzen, außer ein bestimmtes?

Bis demnächst
Matthias

[j4nk3y]

Hey,

[id=id_value] { Stileigenschaften }

Ich bräuchte aber eine Negierung, d.h. id nicht = id_value.

Da du eine ID nur einmal setzen darfst, wären das alle anderen Elemente, daher macht eine Negation keinen Sinn.

Gruß
Jo

[MudGuard]

Hi,

[id=id_value] { Stileigenschaften }

Ich bräuchte aber eine Negierung, d.h. id nicht = id_value. Kann man so etwas auch realisieren?

:not() benutzen.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Forster,

eine ID-Abfrage in CSS macht man nicht über eine Attribut-Abfrage. Für IDs hat CSS eine eigene Schreibweise:

/* umständlich */
[id=foo] { ... }

/* idiomatisch für CSS */
#foo { ... }

Das wirst Du mit :not(#foo) vermutlich invertieren können, aber dann triffst Du wirklich alles und jedes. Würdest Du ein (weißes) Haus rot anstreichen, dann neben der Haustüre eine kleine herzförmige Abklebung anbringen und dann mit einem Helikopter das ganze Haus mit weiß einsprühen, um neben der Haustüre ein kleines rotes Herz zu bekommen? Und dann merken, dass Du nun dummerweise weiß übersprühte Fenster hast, und Dachrinnen, und Türen, und den Vorgarten dazu? Dein :not(#id) ist diese Abklebung und die Eigenschaften darin das Weiß, das der Helikopter versprüht.

Also: Style deine Elemente so, wie Du es brauchst. Überschriften, Paragraphen, Abschnitte, Listen, Menüpunkte, von außen nach innen, und dann gib deinem #foo Element exakt die Eigenschaften, die noch nicht passen. Wenn Du unbedingt etwas universell stylen willst, dann kannst Du auch den * Selektor nehmen, der trifft jedes Element - das braucht man aber eigentlich nur für Basics, z.B. box-sizing, margin oder padding-Defaults für das Dokument.

Rolf

[Matthias Apsel]

Hallo Rolf B,

Das wirst Du mit :not(#foo) vermutlich invertieren können,

Naja, wenn man meine Frage zugrundelegt, würde [id]:not(#foo) zielführend sein.

Bis demnächst
Matthias

[Rolf B]

Hallo Matthias,

besser als :not(#id) ist das auf jeden Fall und für den Moment kann es zielführend sein.

Aber es ist fragil. Ein unbeschränktes :not() ist eine Tretmine. Irgendwann fügst Du ein neues Element ein, irgendwo auf der Seite, gibst ihm eine ID, und dann greift merkwürdigerweise diese Regel. Wenn dein CSS auf 7 Regeln besteht, kannst Du es noch beherrschen. In einem größeren Projekt halte ich das für ein Antipattern.

Für akzeptabel halte ich :not(), wenn es für einen (durch positive Formulierung) klar begrenzten Bereich genutzt wird. table.zonk td:not(:nth-of-type(3)), also alle Spalten in .zonk-Tabellen, außer der dritten", das wäre denkbar. Ich würde dann aber trotzdem lieber eine generische Regel für die ganze Zeile machen und eine Zusatzregel für die 3. Spalte. Also, im folgenden Fiddle - besser .funk als .zonk: https://jsfiddle.net/zgukhjLn/

Rolf

[marctrix]

Hej Rolf,

besser als :not(#id) ist das auf jeden Fall und für den Moment kann es zielführend sein.

Aber es ist fragil. Ein unbeschränktes :not() ist eine Tretmine.

Zudem eines mit einer sehr hohen Spezifität. Gar nicht gut!

Für akzeptabel halte ich :not(), wenn es für einen (durch positive Formulierung) klar begrenzten Bereich genutzt wird. table.zonk td:not(:nth-of-type(3)), also alle Spalten in .zonk-Tabellen, außer der dritten", das wäre denkbar.

Nur einfache/simple Selektoren sind erlaubt:

A simple selector is either a type selector, universal selector, attribute selector, class selector, ID selector, or pseudo-class.

Erstaunlich. Musste erst noch mal nachlesen, aber da nth-of-type eine Pseudoklasse ist, sollte es tatsächlich ein simpler Selektor sein und funktionieren.

Marc

[Matthias Apsel]

Hallo marctrix,

Aber es ist fragil. Ein unbeschränktes :not() ist eine Tretmine.

Zudem eines mit einer sehr hohen Spezifität. Gar nicht gut!

Mit gar keiner. Er erhält die Spezifität seines Arguments.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Aber es ist fragil. Ein unbeschränktes :not() ist eine Tretmine.

Zudem eines mit einer sehr hohen Spezifität. Gar nicht gut!

Mit gar keiner. Er erhält die Spezifität seines Arguments.

Ich bezog mich darauf, dass das Argument eine ID sein soll 😉

Aber Dein Hinweis ist wichtig, weil das so im Zitat nicht stand und nur im Thread−Kontext erkennbar ist…

Marc

[Rolf B]

Hallo marctrix,

Nur einfache/simple Selektoren sind erlaubt:

... noch :).

Selectors Level 4 erweitert das auf eine „selectors list“ - sprich: das volle Kaliber, ist aber laut caniuse bisher nur in Safari umgesetzt.

Rolf

[Gunnar Bittersmann]

@@marctrix

Zudem eines mit einer sehr hohen Spezifität. Gar nicht gut!

Wenn man weiß, was man tut, dann ist Spezifität ein Freund, kein Feind. Just saying.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Zudem eines mit einer sehr hohen Spezifität. Gar nicht gut!

Wenn man weiß, was man tut, dann ist Spezifität ein Freund, kein Feind. Just saying.

Hier in dem Fall ist eine hohe Spezifität ein Nachteil. Spezifität ist ein wichtiger Aspekt der kaskade und wir sind schon lange gut befreundet. Ich habe auch keine Angst für ids und verwende die auch ohne Scham, wenn das html ohnehin eine anbietet.

Passt hier aber alles nicht. Just saying. 😉

Marc

[Gunnar Bittersmann]

@@Rolf B

Für IDs hat CSS eine eigene Schreibweise

Es ist zwar so, dass .bar äquivalent zu [class~='bar'] ist, aber #foo ist was anderes als [id='foo'].

LLAP 🖖

[Rolf B]

Hallo Gunnar,

elaborate, please. Ist der Unterschied semantisch oder „nur“ Performance?

Edit: Ok, scratch that, hab's gefunden. IDs haben eine höhere Spezifität als Klassen- und Attributselektoren. Deswegen hätte p#foo Vorrang vor p[id=foo], aber p.foo und p[class~=foo] sind gleichwertig.

Rolf

[Forster]

Hallo, das Ziel hätte ich genauer beschreiben müssen. In Wordpress gibt es ein Plugin, das ich nicht verändern will. Über eine CSS-Angabe möchte ich eine Button-Ansicht verändern. Allerdings nur einen von zwei vorhandenen. Der eine hat eine ID aber der, den ich verändern möchte aber nicht. Daher die Idee "input[type="submit"][ID** not **= 1212]"

[marctrix]

Hej Forster,

In Wordpress gibt es ein Plugin, das ich nicht verändern will.

Sicher gibt es andere Möglichkeiten der Selektion über Nachfahren, Kinder usw. Müsstest mal die Seite zeigen oder den entsprechenden Quellcode posten, wo man das Element im Zusammenhang sieht oder einen Link zu einer PlugIn-Demo.

Dann könnten wir vielleicht alternative Vorschläge für ein geschicktes Selektieren machen.

Marc

[Forster]

Hallo, reicht der folgende Ausschnitt (die gesamte source ist sehr lang und unübersichtlich)? Der zweite submit, ohne id-angabe soll über CSS verändert werden.

......

<form role="search" method="get" id="searchform" class="searchform" action="........de/">
				<div>
					<label class="screen-reader-text" for="s">Suche nach:</label>
					<input type="text" value="" name="s" id="s" />
					<input type="submit" id="searchsubmit" value="Suche" />
				</div>
			</form>
.........			
.........

<div role="form" class="wpcf7" id="wpcf7-f184-p376-o1" lang="de-DE" dir="ltr">
<div class="screen-reader-response"></div>
<form action="/schreiben-sie-uns/#wpcf7-f184-p376-o1" method="post" class="wpcf7-form" novalidate="novalidate">
<div style="display: none;">
<input type="hidden" name="_wpcf7" value="184" />
<input type="hidden" name="_wpcf7_version" value="5.0" />
<input type="hidden" name="_wpcf7_locale" value="de_DE" />
<input type="hidden" name="_wpcf7_unit_tag" value="wpcf7-f184-p376-o1" />
<input type="hidden" name="_wpcf7_container_post" value="376" />
</div>
<p><label>Name*<br />
..........
..........
<p>**

<input type="submit" value="Absenden" class="wpcf7-form-control wpcf7-submit" />

**</p>
<div class="wpcf7-response-output wpcf7-display-none"></div></form>

[Gunnar Bittersmann]

@@Forster

<form role="search" method="get" id="searchform" class="searchform" action="........de/">
				<div>
					<label class="screen-reader-text" for="s">Suche nach:</label>
					<input type="text" value="" name="s" id="s" />
					<input type="submit" id="searchsubmit" value="Suche" />
				</div>
			</form>

Gehört das auch zu dem Plugin? Wenn nein, kannst du aus <input type="text"> noch <input type="search"> machen.

<div role="form" class="wpcf7" id="wpcf7-f184-p376-o1" lang="de-DE" dir="ltr">

Das ist das Plugin? Da hat der Autor keinen Schimmer, was er da anrichtet. <div role="form"> ist Schwachsinn; role="form" muss da weg. Das form-Element hat die Rolle "form", und es sollen nicht zwei Formulare ineinender verschachtelt werden.

<div style="display: none;">
<input type="hidden" name="_wpcf7" value="184" />
<input type="hidden" name="_wpcf7_version" value="5.0" />
<input type="hidden" name="_wpcf7_locale" value="de_DE" />
<input type="hidden" name="_wpcf7_unit_tag" value="wpcf7-f184-p376-o1" />
<input type="hidden" name="_wpcf7_container_post" value="376" />
</div>

Ja nee is’ klar, versteckte Elemente lieber nochmal verstecken; doppelt hält ja bekanntlich besser.

LLAP 🖖

[Forster]

@Gunnar:

Gunnar schrieb: Das ist das Plugin? Da hat der Autor keinen Schimmer, was er da anrichtet. <div role="form"> ist Schwachsinn; role="form" muss da weg. Das form-Element hat die Rolle "form", und es sollen nicht zwei Formulare ineinender verschachtelt werden.

Das Plugin ist Contact Form 7 | Von Takayuki Miyoshi Ich hab das Projekt so übernommen.

[Forster]

Hallo, alle beide forms kann ich nicht direkt ändern. Wie sieht dann eine sinnvolle Lösung aus? Ich habe jetzt so viele Beiträge, von denen ich viele nicht verstehe.

[Gunnar Bittersmann]

@@Forster

Wie sieht dann eine sinnvolle Lösung aus?

Du willst den Submit-Button innerhalb des Formulars <form action="/schreiben-sie-uns/#wpcf7-f184-p376-o1" method="post" class="wpcf7-form" novalidate="novalidate"> stylen? (Der im anderen Formular ist ja der mit einer ID.)

Oder willst du alle Submit-Buttons auf allen Seiten dieser Website außer demjenigen in dem Such-Formular stylen?

Die Antwort auf diese Frage ist wichtig für das weitere Vorgehen. Wenn diese Seite gegenw¥artig die einzige Seite mit Formaularen ist, bedenke, dass sich das zukünftig ändern könnte und beziehe weitere Seiten mit Formularen in deine Überlegung ein.

LLAP 🖖

[Forster]

Hi, Auf der geamten Website kommen nur die folgenden drei Varianten vor.

<input type="submit" id="searchsubmit" value="Suche" />
<input type="submit" class="adminbar-button" value="Suchen"/></form>

<input type="submit" value="Absenden" class="wpcf7-form-control wpcf7-submit" />

Nur die dritte Variante soll verändert werden. Dass ein weiterer Button hinzukommt, ist äußerst unwahrscheinlich, da sich nur wenig inhaltlich ändert - ich hätte die Seite nie mit wordpres erstellt😉

[Gunnar Bittersmann]

@@Forster

Dass ein weiterer Button hinzukommt, ist äußerst unwahrscheinlich, da sich nur wenig inhaltlich ändert

Die Frage war nicht, wie wahrscheinlich das ist, ob noch ein Button auf einer weiteren Seite hinzukommt. Erfahrung: Immer wenn man sagt: das passiert nie, dann passiert’s doch.

Die Frage ist: Was soll passieren, wenn noch ein Button hinzukommt? (Wenn hier im Sinne von englisch when, nicht if.) Um die Beantwortung hast du dich gedrückt.

Der dritte vorhandene Button gibt nicht wirklich eine Antwort darauf, da er sich dem Namen nach im Admin-Bereich befindet und mit den Buttons, die die Nutzer zu sehen kriegen, nichts zu tun hat.

---

Wenn du den einen Button ansprechen willst, ginge das ja über die Klasse: .wpcf7-submit. Die ist zielmlich kryptisch. Wo kommt die her? Vom Theme? Kann man sicher sein, dass die sich nicht ändert? Vielleicht nicht unbedingt.

Es ginge aber auch über das value-Attribut: input[value="Absenden"]. Das ist recht unsicher, es könnte ja noch andere Eingabefelder mit einem solchen value-Attribut geben.

Sicherer wäre da input[type="submit"][value="Absenden"]. Das könnte für deine Belange reichen.

Das Formular <form action="/schreiben-sie-uns/#wpcf7-f184-p376-o1" method="post" class="wpcf7-form" novalidate="novalidate"> gibt auch nicht so viel her. Höchstens vielleicht den Anfang /schreiben-sie-uns/ des action-Attributs. Das ließe sich noch nutzen, um nur den Button nur dann zu stylen, wenn er sich in diesem Formular befindet:
form[action^="/schreiben-sie-uns/"] input[type="submit"][value="Absenden"]

LLAP 🖖

[Forster]

Hallo,

Die Frage ist: Was soll passieren, wenn noch ein Button hinzukommt? (Wenn hier im Sinne von englisch when, nicht if.) Um die Beantwortung hast du dich gedrückt.

Ich gehe davon aus, dass dies nicht nur äußerst unwahrscheinlich ist sondern fast ausgeschlossen. Diesen würde ja ich selbst hineinbauen, und wenn der sich seltsam verhalten würde, müsste ich dies entsprechend berücksichtigen. Die kryptischen Bezeichnungen, wie .wpcf7-submit, kommen aus dem Kontakt-Plugin. Auch hier sehe ich eine äußerst unwahrscheinliche Änderung als unkritisch an. Wenn die betroffene Seite für Stunden oder Tage nicht korrekt oder gar nicht verfügbar ist, so ist dies nicht tragisch. Ich werde es daher mit Deinem Vorschlag

form[action^="/schreiben-sie-uns/"] input[type="submit"][value="Absenden"]

versuchen.

Danke an alle!

[Ross]

... und es hat geklappt, und es wird auch zukünftig funktionieren, da entgegen der Meinung der Skeptiker in diesem thread keine weiteren "Störelemente" kommen werden. Und wenn doch (wie jemand antworten mag), die Website ist so klein und übersichtlich, dass dies schnell in den Griff zu bekommen wäre. (80:20-Lösung)

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Es ginge aber auch über das value-Attribut: input[value="Absenden"]. Das ist recht unsicher, es könnte ja noch andere Eingabefelder mit einem solchen value-Attribut geben.

Sicherer wäre da input[type="submit"][value="Absenden"]. Das könnte für deine Belange reichen.

Ich sehe nicht, dass sich da Sicherheit erhöht. Submit und Absenden passt wie Arsch auf Eimer. 🤣

Bis demnächst
Matthias

[Ross]

Gunnar hat recht:

Sicherer wäre da input[type="submit"][value="Absenden"]. Das könnte für deine Belange reichen.

Für meine Belange reichts.

[marctrix]

Hej Gunnar,

@@Forster

Dass ein weiterer Button hinzukommt, ist äußerst unwahrscheinlich, da sich nur wenig inhaltlich ändert

Die Frage war nicht, wie wahrscheinlich das ist, ob noch ein Button auf einer weiteren Seite hinzukommt. Erfahrung: Immer wenn man sagt: das passiert nie, dann passiert’s doch.

WordPress gibt den Namen der aktuellen Seite imho (kann gerade nicht nachschauen) im öffnenden body oder html-Tag aus. Das könnte man noch zur Einschränkung nutzen…

Wenn du den einen Button ansprechen willst, ginge das ja über die Klasse: .wpcf7-submit. Die ist zielmlich kryptisch. Wo kommt die her? Vom Theme? Kann man sicher sein, dass die sich nicht ändert? Vielleicht nicht unbedingt.

Doch. Das steht für WordPress Contact Form 7. das ist der Name der Erweiterung und der wird sich nicht ändern. „7“ ist Teil des Namens, keine Versionsangabe.

Sicherer wäre da input[type="submit"][value="Absenden"]. Das könnte für deine Belange reichen.

Nicht, wenn mit der Erweiterung noch ein Formular erstellt wird - ich glaube aber die Formulare erhalten eine eindeutige Kennzeichnung mittels Klasse und/ oder ID - kann jetzt nicht nachschauen (immer noch nicht)… 😉

form[action^="/schreiben-sie-uns/"] input[type="submit"][value="Absenden"]

Das „Schreiben Sie uns“ ist zwar eindeutig diesem Formular zugeordnet, ich würde aber nicht drauf wetten, dass das bleibt, wenn das Formular mit „nimm Kontakt auf“ überschrieben wird. Text-Änderungen kommen mindestens genau so oft vor, wie „oh ich brauche doch noch ein zweites Formular“.

Da hilft ein Blick in die Doku.

Wie gesagt würde ich nach einer Nummer o.ä. suchen. Das Plugin erlaubt ein einmal erstelltes Formular beliebig oft einzubauen…

Ist eigentlich ein gutes Plugin. Das meist verwendete auch.

Marc

[marctrix]

Hej Forster,

Ich war bis jetzt unterwegs, schaue es mir gleich noch mal an!

Marc

[marctrix]

Hej Forster,

Hallo, reicht der folgende Ausschnitt

Ja. Da steht doch am zweiten eine Klasse, die es beim ersten nicht gibt: wpcf7-submit.

Das heißt du kannst darüber die Styles zuweisen. So geht das beispielsweise für einen roten Rahmen:

.wpcf7-submit {
  border: 5px solid red;
}

Marc

[Gunnar Bittersmann]

@@Forster

Allerdings nur einen von zwei vorhandenen. Der eine hat eine ID aber der, den ich verändern möchte aber nicht. Daher die Idee "input[type="submit"][ID** not **= 1212]"

Dann mach das doch so. Wie [ID** not **= 1212] in CSS aussieht, wurde ja schon gesagt.

Wenn du das allerdings ins Stylesheet schreibst, dass auf allen Seiten dieser Website eingebunden wird, dann selektierst du damit auch alle Submitbuttons (die nicht buttons sind) auf allen anderen Seiten. Vielleicht nicht die beste Idee.

Hat das betreffende Formular eine ID einen namen oder sonstwas, was es von anderen Formularen unterscheidet? Dann kannst du den Nachfahrenselektor einsetzen.

Aber Moment mal: das betreffende Formular hat zwei Submitbuttons? (Über den Sinn will ich jetzt mal nicht spekulieren.) Dann sollten diese doch sicher verschiedenes tun, also verschiedene Werte für name/value-Attribute haben, anhand derer du sie unterscheiden kannst.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

es sind 2 Forms, beim zweiten hat er Identifikationsprobleme.

Wenn es um einen Hack geht, könnte man versucht sein, es so machen:

input[type=submit][value="Absenden"] {
   color:white; 
   background-color:darkred;
}

Ich bin nur sehr im Zweifel, ob man das tun sollte - wird die Seite übersetzt (z.B. von Google Translator), greift die Regel nicht mehr.

Man kann den Selektor aber auch mit einem Selektor auf die umgebende Form würzen; das scheint auch eindeutig zu sein:

form.wpcf7-form input[type=submit] {
   foo: bar;
}

Rolf

[Gunnar Bittersmann]

@@Rolf B

… geht übrigens auch. …

Man kann es auch noch mit einem Selektor auf das Form würzen:

Beides schrieb ich.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

yup, Lesen hilft. Sich merken was man gelesen hat macht die Sache optimal :(

Nachtragen muss ich: Du zitiertest

… geht übrigens auch. …

parallel habe ich meine Zweifel bekommen und editiert in:

Ich bin nur sehr im Zweifel, ob man das tun sollte

Mod-Rechte haben auch Nachteile, da hätte ich gern eine Warnung gehabt.

Rolf