Den Web entwickler von FF hab ich installiert, finde es aber nicht.....
Dum meinst vermutlich den "Inspektor", der Firefox sowieso immer dabei hat
Mehrere Wege:
- Rechtsklick auf Seite bzw. Seitenstelle und "Element untersuchen" im Kontextmenü.
- Tastenkombination "STRG+Umschalt+C".
- Menü Extras > Web-Entwickler > Inspektor.
Es geht doch nicht darum, dass irgendein Gesetz verabschiedet wird, dass mit größter Wahrscheinlichkeit keiner Lobby weh tun wird, sondern, ob ein Gesetz verabschiedet wird, dass Leute wie die Petitions-Erstellerin irgendwie entlastet, ohne, dass es überhaupt zu solchen "Gebühren" kommen kann.
Und danach sieht es ganz und gar nicht aus, weil wieder mal die Fürsprecher für diese Leute NICHT berücksichtigt wurden von ALLEN Fraktionen:
Kommt doch auf darauf an, ob es sich um identische Joomla-Version handelt. Bei identischer, z.B. 3, musst die Seite doch nur kopieren und haust dann im Backend allen unbenötigten Erweiterungs-Schotter raus. Zurück bleiben Menüs, Beiträge etc. pp.
Teste die Seite mal mit https://wave.webaim.org/ ob es da auch angemosert wird.
Nein. Das Ergebnis sieht für einen Anfänger-Versuch eh ganz akzeptabel aus, auch, wenn mein ehemals Orange jetzt ein hässliches Braun ist, der Kontratse wegen 
webaim widerspricht an anderer Stelle eigentlich meiner GitHub-PR-Logik. Es gibt einen toTop-Button mit aria-hidden, der keinen Inhalt hat, da er mit CSS befüllt wird. Der wird mir als Fehler angezeigt, weil leer. Bekommt er dann ein aria-label, ist er OK. Soll mir recht sein
Diese Meldung "All page content must be contained by landmarks" kannst du ignorieren, wenn sie sich auf die gesamte Seite bezieht (das <html ).
Ah, den Post habe ich vorhin gar nicht bemerkt. Danke!
Ja, Danke. habe ich zeitgleich auch eingereicht als PR. Hat mich nur zusätzlich aus der Bahn geworfen der Fund
Im Cassiopaia finde ich nämlich für einen Menü-Toggler-Button:
Sorry, wenn ich hier zum Alleinunterhalter werde bei der Lösungsfindung und ständig weitere Fragen nachreiche Mag ich ja ansonsten gar nicht:
Frage für mich ist jetzt, ob ein role="navigation" für den umgebenden Container korrekt ist (weil das für mein Spoiler-JLayout das einfachste wäre). Ich bin einfach unsicher des Toggle-Buttons wegen, der dann innerhalb wäre.
Frage 1.) beantworte ich mir jetzt erst mal mit Ja, aber nur deswegen, weil ich das öfters auf anderen Seiten so sehe. Da weiß man zwar dann nicht gewiss, weil es ja offensichtlich viele Missverständnisse in dem Bereich gibt, aber erst mal OK.
Und bzgl. Teilfrage in 2.) vergrößerst sich meine Wirrnis weiter.
Jetzt muss ich noch was landmark-mäßiges finden für den abgetrennten <button>-Bereich oben, der ja auch als aria-label (aria-labelledby) für das Modal fungiert. Kann ich also nicht plump für Screen-Reader verstecken, die vermutlich(?) nur das Modal-HTML benötigen.
Im Cassiopaia finde ich nämlich für einen Menü-Toggler-Button:
<button class="..." type="button" aria-hidden="true" data-toggle="collapse" data-target="#navbar" aria-controls="navbar" aria-expanded="false" aria-label="<?php echo Text::_('TPL_CASSIOPEIA_TOGGLE'); ?>">Also einerseits ein "Versteck mich für Screenreader"
aria-hidden="true"Auf der anderen Seite zahlreiche "aria-" Auszeichnungen für Screenreader. Was nun, "hidden" oder doch nicht?
Leider nicht. Buttons im Modal, also innerhalb des aufgegangenen PopUps sind alle soweit OK.
Aber ich weiß bei 1) nicht, ob man dem äußersten DIV
<div class="umgebender-container">
, der sowohl den Button zum Öffnen des Modals enthält als auch das Modal-HTML selbst
ein role="navigation" bekommen kann oder nur der
<div class="collapse-bereich">
Ob das eine oder andere eher zu Konfusion führen kann oder komplett egal, so lange der Button und Modal erzählen, dass sie zusammengehören. Der eine klappt die Navigation auf. Der andere ist die Navigation.
Ich blick da eh überhaupt nicht mehr durch. Eigentlich ist der Modal-Inhalt ja sowieso als HTML in der Seite vorhanden, halt nur erst mal versteckt für sehende Besucher. Aber einem Screen Reader sollte das ja eigentlich wurst sein. oder muss man da auch erst den Button "klicken", damit der versteckte Inhalt vorgelesen wird? Aber das ist dann schon wieder eine neue Frage.
1.) Ich habe in einer Seite ein Modul außerhalb anderer Landmarks mit einem Toggler-Button, der eine Liste von klickbaren, internen Seitenlinks öffnet. So in der Art:
<div class="umgebender-container">
<button class="...">
Ich öffne den Collapse-Bereich mit der Seiten-Links-Liste
</button>
<div class="collapse-bereich">
Anker-Link-Liste
</div>
</div>Das ist alles soweit korrekt ausgezeichnet mit A11Y-Kram, zumindest so, dass ich in AXE keine Reklamationen sehe.
Außer "All page content must be contained by landmarks".
Frage für mich ist jetzt, ob ein role="navigation" für den umgebenden Container korrekt ist (weil das für mein Spoiler-JLayout das einfachste wäre). Ich bin einfach unsicher des Toggle-Buttons wegen, der dann innerhalb wäre.
Die 2. Vielleicht-Option wäre ein <nav> statt <div>. Aber letztlich stellt sich mir da die selbe Frage.
2.)
Ich habe im oberen Teil des HTML einen Button, der ein Modal-PopUp öffnet. Das jeweilige Modal-HTML befindet sich am Ende der Seite vor dem schließenden BODY.
Dem Modal-Bereich habe ich jetzt aus Verlegenheit ein role="dialog" gegeben. Vielleicht ja richtig. Zumindest habe ich vorerst nichts besseres gefunden.
Das Modal enthält sowohl Teilen-Knöpfe als auch ein Suchfeld, also "diversen Inhalt".
Jetzt muss ich noch was landmark-mäßiges finden für den abgetrennten <button>-Bereich oben, der ja auch als aria-label (aria-labelledby) für das Modal fungiert. Kann ich also nicht plump für Screen-Reader verstecken, die vermutlich(?) nur das Modal-HTML benötigen.
Blick ich also nicht mehr durch...
Wird zwar wahrschsinlich hier nicht helfen:
Fehler finden durch detailliertere Fehlermeldung. Debug-Modus. Call stack.
Weiters kannst probieren, den Ordner des Plugins per FTP umzubenennen, damit du wieder rein kommst. Damit ist es auch deaktiviert.
Ist vermutlich
/plugins/system/cookiehint/
Hikashopmodule = hikashop_cart
Kenn ich mich gar nicht aus.
muss ich dass dann eben bei dem Modul genau so machen?
WENN es diese Art des Overrides (eigenes Layout) unterstützt, sich also an Joomlastandards hält, GRUNDLEGEND ja, aber vermutlich nicht exakt so, weil ja der ganze andere PHP-Code abweichen wird.
Oder bleiben diese Moduländerungen dann auch bestehen?
Sog. Joomla-Template-Overrides (siehe https://www.j-over.de/de/) sind exakt dafür da, dass sie bei Updates unberührt bleiben. Natürlich kann es immer mal eine Änderung in zuinstallierten Erweiterungen geben, so, dass der eigene Override floppt. Aber dann schreibt man ihn halt um.
Ansonsten bleiben noch die eigenen Modul-Stile (modChrome). Aber da muss man sich halt einarbeiten. Letztlich kann man da die selben Daten abfragen wie direkt im Modul-Template-Override.
Nachtrag zum Thread-Titel:
"Farbe Text, Farbe Hintergrund, Fettdruck" sollte im Normalfall immer unkritisch sein.
"Abstände" kann kritisch sein. Meist Paddings weniger als Margins.
Deshalb auch immer im Firefox zwischendrin mal das Tool "Extras > Webentwickler > Bildschirmgrößen testen" verwenden.
(Alle Browser haben so was in der Art drinnen. Beim Firefox ist der Vorteil (für mich), dass das ein bisschen mehr abgekopelt ist vom Inspektor, der da nicht immer gleich zusätzlich aufgeht.)
Nachtrag 2:
Und natürlich kannst du Anweisungen "dazuerfinden", die in der template.css so nicht explizit stehen. Am obigen Beispiel
.nav-pills > .active > a
{
background-color: yellow;
}.nav-pills > .active > a
{
background-color: yellow;
cursor: cross-fade;
border: 1px solid black;
line-height: 120%;
}Ist jetzt natürlich nur "wilder Unsinn", was ich da genommen habe. Creativity rules!
Soll ich das so in die user.css kopieren? Was passiert dann?
Kann mir aber nicht vorstellen, dass das so einfach ist.
Doch das ist es.
Die user.css überschreibt die template.css. Ohne, dass was "passiert", weil du ja die user.css auch wieder zurückändern kannst. Die template.css bleibt ja unverändert bei deinen Aktionen und du kannst so jederzeit wieder zurück.
Beide CSS-Dateien werden geladen. Erst die template.css, dann die user.css. Die Reihenfolge ist entscheidend. Was in der user.ccs steht hat Priorität vor den Anweisungen in der template.css. Was nicht in der user.css steht, wird von der template.css abgewickelt.
In deinem Bild sehe ich z.B., dass das Element, das du links inspizierst mit
.nav-pills > .active > aangesprochen wird, weil das in dem Kuddelmuddel rechts schwarz hervorgehoben wird.
Es würde also grundlegend reichen, wenn du nur exakt das Ding anpassen willst und nur die background-color eben nur diesen Teil in die user.css zu übernehmen.
.nav-pills > .active > a
{
background-color: yellow;
}Wenn du in diesem Block, den du oben postest, nur das Padding ändern willst
.nav-pills > li > a {
padding-top: 8px;
padding-bottom: 8px;
margin-top: 2px;
margin-bottom: 2px;
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;
}reicht also in der user.css
.nav-pills > li > a {
padding-top: 28px;
padding-bottom: 28px;
}Alle anderen Formatierungen werden wie gehabt aus der template.css gezogen. Kannst natürlich auch die ganzen Blöcke kopieren, wenns einfacher für dich ist.
Grundlegend hast schon recht mit der Befürchtung
Ich weiß, dass nav-list und nav-pills etwas mit dem Menüdesign zu tun haben und für mich hieß das bisher : Finger weg... sonst bringst Du alles durcheinander
Es gibt CSS-Anweisungen, z.B. direkt für den umschleißenden Container,
.nav-pills {
}neben einigen anderen im CSS-System, die bei Änderung was global "kaputt" machen könnten. Dass z.B. auf veränderten Bildschirmbreiten unerwartet das Aussehen zerlegt und bei manchen CSS-Anweisungen/-Klassen sogar an Stellen, wo man nicht erwartet hätte, weil die eben die selbe Klasse nutzen.
In anderen Fällen könnte das
.nav-pills > li > avielleicht auch ein anderes nav-pills-Menü ansprechen, z.B. im Fuß der Seite und da will man das aber gar nicht.
Dann muss man die Anweisungen in der user.css exakt auf das Top-Menü ansetzen.
Dafür hast dann dieses Forum, damit man dir hilft. Bräuchte man allerdings als Helfer oft einen Link.
Du legste eine Datei user.css im selben Ordner wie die template.css ab.
Du findest in der template.css so was in der Art
.diesda {
color: green;
}
Du kopierst den Block in die user.css und änderst ihn.
.diesda {
color: red;
}
Wenns nicht wirkt siehst im Inspektor nach, ob deine Zeilen ausgegraut sind. Dann musst die Anweisung in der user.css verschärfen.
Im Zweifelsfall mit einem !important
.diesda {
color: red !important;
}
Es gibt mehrere Stellen. Die aus der Konfiguration werden dann genommen, wenn keine im Menü eingetragen sind oder im Beitrag oder in der Kategorie.
Hast du denn das geprüft. Irgendwo werden sie schon stehen
Werden die Daten ev. wo anders geänder
Es gibt mehrere Stellen. Die aus der Konfiguration werden dann genommen, wenn keine im Menü eingetragen sind oder im Beitrag oder in der Kategorie.
Da kommt dann eine gewisse Hierarchie ins Spiel, welche wann gezogen werden.
Das ist auch richtig so, da jede MetaBeschreibung zur gerade individuell angezeigten Seite passen sollte. Überall die selbe ist ziemlich sinnfrei.
Wills keinem ausreden, aber die Meta-Keywords werden schon länger gar nicht mehr von Suchmaschinen ausgelesen. Mag noch ein paar Spartensuchmaschinen geben. Aber auch da gilt das oben gesagte. Wenn, dann individuell für jede einzelne Seite angepasst.
Du schreibst, nun machst du dein eigenes Ding! und das mit Joomla 3
Jetzt wirds privater, was ich eigentlich vermeiden wollte:
Weil man Bootstrap-4, SASS, Grid-CSS und anderes auch mit Joomla 3 lernen kann. Ob ich mit Joomla-4 weitermache oder mir ein neues Aufgabenfeld suche oder Hartz4 beantrage, stellt sich raus, wenn das erste stabile Joomla 4 rauskommt. Dann teste ich ein paar Wochen die Dinge, die mich angehen.
Ich persönlich habe J4 ausgiebig beäugt und in der Praxis getestet und sehe 2, 3 gravierende "Inkompatibiltäten", die so viel zusätzliche Arbeit benötigen (könnten) und sogar Teile meiner joomlanahen Programmier-Arbeit der letzten Jahre komplett für den Ar... ohne Ausgang machen könnten, weil sich ein paar selbstverliebte Nerds durchgesetzt haben, dass für mich diese Version derzeit kein Thema mehr ist. Also mache ich mein eigenes Ding und schaue mir andere Systeme und Techniken an, anstatt meine Zeit mit Unmöglichkeiten zu verbringen und mich darüber zu ärgern, dass J4 lange notwendige Korrekturen in der Core-Grundarchitektur nicht umgesetzt hat oder nur halbschürig irgendwas aufgepropft hat, der "Modernität" wegen, anstatt frühzeitig einen klaren Schlussstrich für "Altes" zu ziehen oder die Sachen auf J!5 zu verschieben. Dabei ist es nicht so, dass andere, die weitaus mehr Durchblick haben als ich (= Autodidakt), nicht beizeiten davor gewarnt hätten bzw. konstruktive Kritik geübt hätten.
Aber, und das ist entscheidend für Nutzer, so lange es Programmierer gibt, die bereit sind, sich darauf einzustellen, bleibt Joomla für Nutzer wie es ist, mit ein paar neuen Features und ein paar weniger an Stellen, wo sie für die meisten nur Last waren. Und es wird Erweiterungen von fleißigen Leuten geben, die alte Features zurückbringen
Und auch Leute wie ich werden weiterhin in der Lage sein, Joomlas, Templates, Erweiterungen etc. pp. auf 4 zu migrieren oder es Kunden einzurichten oder was zuzuprogrammieren usw. usf. Aber die "Freude an komplexerer Kreativität" ging verlustigt. Kann ich auch Regale auffüllen.
Deshalb mein eigenes Ding... Komplett rücksichtslos...
Abgesehen davon, dass du dich jetzt meines Empfindens nach etwas unverschämt weit aus dem Fenster lehnst und von ehrenamtlichen "Mitarbeitern" noch mehr Engagement erwartest... Na, ich lass das mal gut sein. Vielleicht verstehe ich deine Anmerkungen auch einfach falsch.
Du wolltest wissen woher die !important-Klassen kommen. Das habe ich klar gelegt. Nämlich, dass es keine Schikane ist, sondern eben ein Mitbringsel von Bootstrap-4, das man nutzen kann oder nicht. Entscheidend ist nicht, was in der CSS-Datei liegt, sondern, was davon im HTML-Code genutzt wird.
Nachdem man sich bei Joomla-4 mittendrin entschieden hat, den Internet-Explorer zu ignorieren, konnte man es sich eben leisten, Bootstrap-4 in großen Teilen zu vergessen, aber trotzdem noch ein paar nette Features beizubehalten. Daher kommt dieses "Mischmasch" im Casseiopaia.
Wenn du dich in Bootstrap-4 einarbeiten willst, gibt es hier eine hervorragende Doku (https://getbootstrap.com/docs/4.3/layout/overview/), die dann aber wieder von dir erhöhtes Engagement erwartet, als nur zu fordern und abzuholen
Wenn du lieber auf die Fähigkeiten moderner Browser vertraust, also ohne Einschleppen von externem CSS wie Bootstrap, lohnt vielleicht eine Einarbeitung in "CSS Grid Layout" (das meinte skodi ). Hier eine kurze Einführung, die genug Stichworte liefert, um sich anderswo Tipps und Tricks zusammenzususchen und auszuprobieren (https://www.w3schools.com/css/css_grid.asp).
Wenn du gezielt fragen zur Umgestaltung deiner Seite hast, findest du in den Forenregeln wie du die Fragen stellen solltest, zielgerichtet. Wird man dir meist helfen können.
Wenn du an Templates was ändern willst, musst du dich in jedem System mindetstens in HTML oder CSS einarbeiten. Sonst musst halt warten bis Joomla-4-Templates am Markt sind. Und wie Indigo66 andeutet, werden da viele Variationen bei sein, weil man jetzt eben etwas freier bei der Gestaltung ist. Auf der anderen Seite werden Erweiterungsprogrammier teils große Probleme kriegen, weil es eben kein verpflichtendes Grundsystem mehr gibt, auf das man CSS-technisch "blind" aufsetzen kann.
Von 2 Templates rede ich, weil es eines fürs Frontend und eines fürs Backend (Administration) gibt. Selbstverständlich kann man beide durch eigene und fremde ersetzen.
Und das "Kompilieren" war eine Antwort auf skodi . Aber wer kein CSS kann, hat da nicht viel von gleich bei SASS anzufangen. Oder, warum eigentlich nicht... Das CSS der beiden Templates wird halt aus SASS kompiliert. Der End-User muss sich davon nicht tangieren lassen!!!!!! Kann ihm wurst sein. Und in diesem Fall, "Kompilieren von SASS nach CSS" gibt es ein Joomla-Plugin von einem Freiwilligen. Es gibt auch plattformübergreifende stinknormale Programme, die einem per Drag&Drop was "kompilieren".
Joomla ist ein offenes System. Man darf alles tun und lassen, was man will. Auch in Linux schraubt man nicht an Core-Bibliotheken
Jetzt habe ich noch das Problem dass der Editor JCE nicht angezeigt wird
. Weiß jemand warum?
Vielleicht gibt es kein passendes JCE-Editor-Profil für den Benutzer und/oder Gruppe und/oder Frontend.
Daran denken, dass die JCE-Profile von oben nach unten durchprobiert werden. Das erste, was auf einen Benutzer zutrifft, wird dann genommen.