HTML Opacity 0.7 styled das darunterliegende Image mit

[Sithys]

Hallo zusammen,
ich arbeite gerade an einer iOS/Android App auf Basis von HTML5. Ich möchte den zuletzt besuchten Button in meiner Navigation einfärben, damit der User weiß, wo er her kommt.

Dazu benutze ich zunächst dieses Javascript:

 <script language="javascript">
	function hide_selection(){
		var lnks = document.getElementsByTagName("A");
		for(i=0; i<lnks.length; i++){
			if (lnks[i].className == "selected_link"){
				lnks[i].className = "";
				break;
			}
		}
	}
	
	function selectLink(ob){
		hide_selection();
		ob.className = "selected_link";
	}
</script>

Mein CSS

.selected_link {
    background: repeat-y scroll 15px 6px #00FF00;
    position: relative;
    clear: both;
    float: left;
    opacity: 0.7;
}

Mein Link hat als onclick-event "selectLink(this)"

<li>
  <a href="#news" data-transition="slide" onclick="selectLink(this);">
    <img src="img/start/btnnews.png" width="320px" height="40px" class="link" />
  </a>
</li>

Im Browser funktioniert alles wie gewollt. Aber auf dem iPhone scheint die Transparenz für den grünen Overlay UND das darunterliegende Bild zu gelten. Habe schon versucht, das img über

a img{
    opacity: 1.0 !important;
}

anzusprechen, aber das bringt leider keine Besserung. Auch die Klasse .link mit

.link{
 opacity: 1.0 !important;
}

anzusprechen nützt nichts. Hat von Euch noch jemand eine Idee, wie ich die Transparenz für den Overlay beibehalten kann, meinem Image aber die Transparenz 100% gebe (nämlich keine)?

Danke vorab!

 

[Yuuri]

Ist auch eigentlich vollkommen korrekt so und ich würde mich wundern, wenn das Bild nicht mit in der Durchsichtigkeit geändert werden würde. Du änderst ja den kompletten Container (inkl. allem was da drin liegt) und nicht nur den Container selbst.

 

[[ChAoZ]]

http://jquery.com/ ist dein Freund.

 

[Sithys]

Das hab ich schon begriffen,...das a tag umschließt ja das img. Im Browser wird aber nur die Klasse "selected_Link" gestyled ohne image. Wie kann ich das Problem denn lösen? Dem image noch mal opacity mit 1.0 zu geben geht ja nicht.

Ergänzung (5. Juni 2014)

Man, sind das konstruktive Antworten hier heute...

<link rel="stylesheet" type="text/css" href="css/jquery.mobile-1.4.2.css" />
        <link rel="stylesheet" type="text/css" href="css/flexislider.css" />
        <link rel="stylesheet" type="text/css" href="css/stylesheet.css" />
        <script type="text/javascript" src="js/jquery-1.11.1.js"></script>
        <script type="text/javascript" src="js/jquery.mobile-1.4.2.js"></script>
        <script type="text/javascript" src="js/jquery.simpleWeather.min.js"></script>
        <script type="text/javascript" src="js/jquery.flexislider.js" media="screen"></script>

 

[[n]ARC]

arbeite mit :before (oder hover) und vergib dem bild eine klasse, die du direkt ansteuerst. dies ist die schnellste lösung, wobei ich das etwas anders gelöst hätte

wenn du nicht unbedingt <IE9 support brauchst, könntest du die opacity über css3 lösen. statt dem ganzen js kram.

 

[Gajel]

So schwer ist google garnicht zu bedienen. Eigeninitiative!

https://www.google.de/search?q=opac...hannel=sb&gfe_rd=cr&ei=E5KQU8WFOsKK8QeQkYDICA

 

[Daaron]

Wie gesagt, das ist vollkommen normal. Opacity "vererbt" nicht wie andere Attribute (z.B. Schriftgröße), sondern Opacity verhält sich wie die CSS3 Transformationen: Es wirkt auf das Element und implizit damit auf dessen Kinder.
Für dich heißt das: Der Inhalt eines halbtransparenten <a> ist genauso halbtransparent. Du kannst die Transparenz des Inhaltes nur noch weiter Richtung 100 (also komplett weg) erhöhen, nicht aber niedriger ansetzen. Analog dazu: Würdest du mit transform:rotate(90deg) das <a> um 90° drehen, dann wäre das Bild implizit mit gedreht. Logisch. Oder denk in Bildbearbeiter-Terminologien: Dein <a> ist die Ebene, dein <img> der Pinsel. Wenn deine Ebene nur 50% Deckkraft hat, dann wird dein Pinselstrich nie die darunter liegende Ebene komplett verdecken können.

Was genau willst du jetzt machen? Irgendwie habe ich das gefühl, du willst eher das hier:

a.selected_link img {opacity:0.7}
/* und natürlich a.selected_link {opacity:1} */

Ergänzung (5. Juni 2014)

arbeite mit :before (oder hover) und vergib dem bild eine klasse, die du direkt ansteuerst.

Kleiner Hinweis hierzu: <img> gehört zu den Elementen, auf die :before/:after keine Wirkung hat. :before/:after sind Pseudo-Inhalt. Ein inhaltsfreies, selbstschließendes Element wie <img> kann da nix einfügen.

 

[[n]ARC]

@Daaron aber das div
wie gesagt ich hätte es eh anders gelöst, eine klarere anforderung wäre besser als irgend nen code den man selbst wohl nicht versteht

 

[Sithys]

Wie hättest du es denn gelöst? Derzeit läuft es leider immer noch nicht. Die Links sind leider durchsichtig und nachdem ich drauf geklickt habe liegt dann das grüne Overlay drüber und nur jenes ist durchsichtig, das bild nicht mehr... alles käse, geht nicht wie gewünscht

 

[WhiteShark]

Geb dem A die volle opacity und mach einfach die Background color mit rbga anstatt hex

 

[Sithys]

Geb dem A die volle opacity und mach einfach die Background color mit rbga anstatt hex

Done, aber leider ohne Änderung:

<a href="#news" data-transition="slide" onclick="selectLink(this);" id="trans">
   <img src="img/start/btnnews.png" width="320px" height="40px" class="link" />
</a>

.selected_link {
    background-color: rgba(0,255,0,0.8) !important;
    position: relative;
    z-index: 100;
    clear: both;
    float: left;
}

#trans{
    opacity: 1.0 !important;
}

 

[Daaron]

Mach aus dem ganzen Scheiß mal ein schönes JS-Fiddle, damit wir uns das mal "live" angucken können. Ich weiß nicht, WAS du hier alles falsch machst, aber es ist definitiv eine ganze Menge.

 

[WhiteShark]

Ein <a> ist übrigens ein Inline-Element. Da bringt es wenig das zu floaten und noch dazu Relative zu machen.
Wenn dann müsstest du es auf inline-block stellen und das float entfernen.

Beim <img> sind die Attribute width und height veraltet. Was jetzt nicht wirklich schlimm wäre, aber die px haben da dann nix verloren.
Zudem ist das Alt-Attribut auf dem <img> laut W3C-Standard Pflicht.


Wenn du aber sagst, das sich beim Klick auf das Bild nichts ändert, dann wird wohl die Klasse nicht gesetzt. Möglicherweise liegt es an den oben genannten Punkten.

 

[Daaron]

Ein <a> ist übrigens ein Inline-Element. Da bringt es wenig das zu floaten und noch dazu Relative zu machen.

Das ist so nicht korrekt. position:relative hat bei Inline-Elementen durchaus Wirkungen:
1.) Absolut positionierte Kindelemente richten sich am nächsten nicht-statischem Elternelement aus
2.) Nur nicht-statische Elemente reagieren auf Z-Index

Beim <img> sind die Attribute width und height veraltet.

Nope, die sind nicht veraltet und tatsächlich sogar sehr nützlich.
WENN man die Bilder nicht anderweitig (über CSS) nachskaliert sorgt eine Angabe von Width & Height (natürlich ohne px) dafür, dass das DOM-Element schneller gerendert wird.

 

[WhiteShark]

Hier in diesem Fall bringt das relative aber wirklich nichts, da im <a> ebenfalls nur ein inline-Element liegt.
Muss aber zugeben, das es mir bisher nicht bekannt war, das Relative auch auf inline-Elemente Einfluss hat. Hab ich bei inline aber auch noch nie verwendet.
Denn wenn ich innerhalb eines Inline-Elements weitere Elemente habe, dann brauch ich es ohnehin meist als inline-block.

Width/height-Attribute sind imo heutzutage schon veraltet. Denn gerade im Responsive-Design wird es dann komplizierter.

 

[Daaron]

http://www.w3.org/TR/html-markup/img.html
http://dev.w3.org/html5/spec-preview/the-img-element.html
Weder Breite noch Höhe sind als obsolet markiert. Wie gesagt, korrekte Werte beschleunigen das Rendering und komplizierter wird bei Responsive Layouts da auch nicht, weil man dann einfach per CSS z.B. img {max-width:100%;height:auto:} setzt.

 

[WhiteShark]

Ich hab ja extra "imo" davor geschrieben.

Ich finde jegliche Größenangaben gehören ins Css.

Wobei das eher offtopic ist. Wichtig ist das die px da nix verloren haben.

 

[Yuuri]

Ich finde jegliche Größenangaben gehören ins Css.

Theoretisch nein, denn Größenangaben gehören direkt zum Bild und will man das Rendering nicht unnötig belasten (dieses wird dann immer unterbrochen, verworfen und neu gestartet), sollte man die Größenangaben dahin packen, wo sie geladen werden und der Parser diese auch gleich miteinbeziehen kann. Die CSS wird immer nachträglich/parallel/unabhängig geladen, ergo gibt es mindestens einen neuen Renderingvorgang, je nach Downloadgeschwindigkeit und Größe des Contents mehrere.

Ich persönlich nutze keine Angaben, das bisschen Verrutschen ist mir dabei egal. Chrome allerdings fliegt auf die Gusche, wenn du Bildergrößen beim DOM Ready haben willst - dort ist alles durchgehend null (außer die Bilder sind bei DOM Ready bereits aus dem Cache geladen worden). Firefox/IE haben damit keine Probleme. Einziger Bugfix ist es den Bildern Größen mitzugeben oder den OnLoad-Handler zu verwenden. Allerdings kann OnLoad hierbei auch gut und gerne mehrere Sekunden/Minuten benötigen, eh das Event feuert.

 

[Daaron]

Yuuri, wenn du das Problem umgehen willst: https://github.com/alexanderdickson/waitForImages
Das Ding führst du im DOM-Ready aus und bindest es an einen passenden Selektor, z.B. das Elternelement eines Sliders.

 

[Sithys]

Die Angaben width und height müssen dort gesetzt werden. Die Bilder sind ja eigentlich doppelt so groß, wie die angegebenen width und height Werte damit sie eine Retina-Auflösung haben.

Das JSFiddle versuche ich fertig zu machen.