Frage zum Wiki-Artikel „iframe“
Hp
- frage zum wiki
- html
Hallo, ich möchte einen Fehler in ihren Beispiel melden. Als width-Parameter kann keine Prozentzahl stehen - es muss zwingend eine Pixel-Angabe erfolgen -> width="1024px". Es wird auch kein style= akzeptiert und schon gar kein class= oder id=.
Hierzu wäre ich für einen tipp dankbar, wie ich den width-Parameter mit einem Pixelwert bestücken könnte, der aus einer Abfrage der tatsächlichen Anzeigebreite ermittelt wird. Ich weiß zwar wie ich diese aktuelle Anzeigebreite mit Javascript ermitteln kann, aber das Ergebnis als Parameter im iframe-tag wie benötigt und erlaubt einzubauen, scheitert daran, dass hier zwischen den Anführungszeichen keine Ausgabe von Javascript erlaubt ist. Hier scheint die Interpretation besonders strikt nach extrem enger Vorschrift zu erfolgen.
Wie also könnte das Problem gelöst werden? Gruß Herbert
Hallo Hp,
ich möchte einen Fehler in ihren Beispiel melden. Als width-Parameter kann keine Prozentzahl stehen - es muss zwingend eine Pixel-Angabe erfolgen -> width="1024px". Es wird auch kein style= akzeptiert und schon gar kein class= oder id=.
das sind keine Fehler, das ist richtig so.
Wie also könnte das Problem gelöst werden?
Vielleicht mit einer Beispielseite und/oder Quelltext von dir.
Gruss
Henry
Servus!
Hallo, ich möchte einen Fehler in ihren Beispiel melden.
Danke für Ihre Mitarbeit!
Als width-Parameter kann keine Prozentzahl stehen - es muss zwingend eine Pixel-Angabe erfolgen -> width="1024px".
Ich denke, Sie beziehen sich auf folgenden Passus:
"The width and height attributes on img, iframe and object are no longer allowed to contain percentages. They are also not allowed to be used to stretch the image to a different aspect ratio than its intrinsic aspect ratio."
https://www.w3.org/TR/html5-diff/#changed-attributes
In der MDN steht noch die Angabe, dass auch Prozentwerte möglich sind.
Im ausführlicheren Tutorial haben wir ein Beispiel, es funktionierte, warf aber einen Fehler im Validator.
Auf SO habe ich folgende Diskussion gefunden: https://stackoverflow.com/questions/26100484/what-are-the-consequences-of-using-percentage-for-width-height-attributes-of-an
Es wird auch kein style= akzeptiert und schon gar kein class= oder id=.
Das sollte mich wundern. So wie ich es verstanden habe, wurde die Möglichkeit der Prozentangabe entfernt, damit jegliche Gestaltung eben durch CSS erfolgen kann.
Ich habe das Frickl-Beispiel entsprechend angepasst:
Fragen an alle anderen:
Hierzu wäre ich für einen tipp dankbar, wie ich den width-Parameter mit einem Pixelwert bestücken könnte, der aus einer Abfrage der tatsächlichen Anzeigebreite ermittelt wird.
Ich weiß zwar wie ich diese aktuelle Anzeigebreite mit Javascript ermitteln kann, aber das Ergebnis als Parameter im iframe-tag wie benötigt und erlaubt einzubauen, scheitert daran, dass hier zwischen den Anführungszeichen keine Ausgabe von Javascript erlaubt ist. Hier scheint die Interpretation besonders strikt nach extrem enger Vorschrift zu erfolgen.
Da das Formatieren mit CSS ja doch geht, würde ich den aus JS ausgelesenen Wert mit setProperty() als custom property setzen.
Im CSS hast du das dann so:
:root {
--mywidth: 90%;
}
#iframe {
width: var(--mywidth);
}
Wie also könnte das Problem gelöst werden? Gruß Herbert
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
In der MDN steht noch die Angabe, dass auch Prozentwerte möglich sind.
Aber nur in der deutschen Übersetzung, die man besser nicht liest. Entweder ist sie teilübersetzt, schlecht übersetzt oder veraltet. Gute deutsche Artikel bei MDN sind selten. Da ist das Selfwiki zumeist besser. In mdn/de steht aber auch eine Unterscheidung HTML 5 und HTML 4, wobei nicht ganz deutlich wird, ob die Prozentinformation zu HTML 4 gehört oder nicht.
Sie gehört zu HTML 4.
Der Fallback-Text im iframe erzeugt einen Fehler im Validator
Naja, muss er auch. Content model: Nothing.
- wie würdet ihr das lösen?
Knifflig. Von der Browserunterstützung her technisch gibt es für diesen Fallback schon lang ekeine Notwendigkeit mehr. Aber zumindest im Internet Explorer kann man iframes per Benutzereinstellung abschalten. Firefox hatte browser.frames.enabled (SO Beitrag von 2016) - jetzt scheinbar nicht mehr. Chrome hat angeblich Extensions, die iframes abschalten können. Und es gibt auch immer die Chance, dass die URL des iframe nicht mehr gültig ist oder nicht lädt.
Eine JavaScript-Lösung bringt da auch nichts, weil ein Paranoiker, der iframes deaktiviert, JavaScript vermutlich genauso abschaltet. Aber ohne JS seh ich da nichts.
Rolf
Hallo
In der MDN steht noch die Angabe, dass auch Prozentwerte möglich sind.
Aber nur in der deutschen Übersetzung, die man besser nicht liest.
Tja, daran scheint man mittlerweile nicht mehr vorbeizukommen. Gerade habe ich auf caniuse.com nachgeschaut, wie mit der Unterstützung der von dir im Nebenast erwähnten Eigenschaft clamp aussieht Wenn man da nur nach einem Begriff sucht, bekommt man, wenn vorhanden, auch mehrere Treffer, hier unter anderem auch types: clamp().
Da es zu diesem auf caniuse.com keine Beschreibung gibt, folgte ich dem Link zur MDN und landete im Nirvana einer browserspracheinstellungsbasierten Umleitung.
Ganz großes Tennis!
Im übrigen gibt es ohne JS nur ein wenig hilfreiches „Page not found“[1] zu lesen. Erst, wenn JS zur Verfügung steht, wird mir angezeigt, dass es die gesuchte Seite nicht auf deutsch aber auf US-englisch gibt. Wie wird es von den Benutzern der MDN angenommen werden, wenn sie automatisch auf die deutschsprachige Version eines vorhandenen Artikels geleitet werden und nicht mehr an die englischsprachige Entsprechung herankommen?
Und alle so: Yeah! [2]
Tschö, Auge
Servus!
Hallo
In der MDN steht noch die Angabe, dass auch Prozentwerte möglich sind.
Aber nur in der deutschen Übersetzung, die man besser nicht liest.
Tja, daran scheint man mittlerweile nicht mehr vorbeizukommen. Gerade habe ich auf caniuse.com nachgeschaut, wie mit der Unterstützung der von dir im Nebenast erwähnten Eigenschaft clamp aussieht Wenn man da nur nach einem Begriff sucht, bekommt man, wenn vorhanden, auch mehrere Treffer, hier unter anderem auch types: clamp().
Da es zu diesem auf caniuse.com keine Beschreibung gibt, folgte ich dem Link zur MDN und landete im Nirvana einer browserspracheinstellungsbasierten Umleitung.
Im Wiki sind zumindest die richtigen Links drin:
Ganz großes Tennis!
Ja, das ist manchmal ganz schön schwierig die passenden Links zu finden. Im SVG-Bereich musste ich feststellen, dass die W3C viel aus SVG in die neuen CSS Modules verschoben hat und die bisherigen Entwürfe einfach gelöscht hat. So liefen die Links aus der Referenz ins Leere. 😟
Herzliche Grüße
Matthias Scharwies
Hallo
Da es zu diesem auf caniuse.com keine Beschreibung gibt, folgte ich dem Link zur MDN und landete im Nirvana einer browserspracheinstellungsbasierten Umleitung.
Im Wiki sind zumindest die richtigen Links drin:
Nun ja, da habe ich in dem Moment nicht geschaut. Ich hatte ja einen zielführenden Link, … dachte ich.
Ganz großes Tennis!
Ja, das ist manchmal ganz schön schwierig die passenden Links zu finden. Im SVG-Bereich musste ich feststellen, dass die W3C viel aus SVG in die neuen CSS Modules verschoben hat und die bisherigen Entwürfe einfach gelöscht hat. So liefen die Links aus der Referenz ins Leere. 😟
Ach, das ist doch Mist. Wie hieß es immer? Cool URLs don't change. Wäre schön, wenn sich zumindest die, die Webstandards festlegen und die offiziellen Dokumentationen bereitstellen, daran hielten. 😕
Tschö, Auge
Hallo Mathias,
danke für den Link mit der Diskussion um die Prozentangabe. War ganz aufschlussreich aber dafür gab es wenigstens einen direkten Ausweg.
Der Fall mit iframe ist hier ein Sonderfall: CSS wird schlicht ignoriert und das iframe gar nicht erst angezeigt. Nicht mal mit der Voreinstellung. In allen anderen Fällen ist natürlich CSS das Mittel der Wahl, nur bei iframe wurde diese Möglichkeit wohl "vergessen" berücksichtigt zu werden.
Herbert
Hallo Herbert,
wenn du uns schon Siezt, dann schreib die Anrede „Ihr“ wenigstens groß 😉. Beim „Du“ darf man heutzutage klein schreiben (ich tu das nicht), und das Du ist hier im Forum üblich.
Zur Frage: Es ist ebenfalls üblich, dass die Dimensionsattribute der HTML Elemente für eingebetteten Inhalt (img, iframe, etc) in Pixeln angegeben werden. Dass man da Prozente verwenden darf durfte, hatte ich gar nicht mehr auf dem Schirm. Das ist ein HTML 4 Relikt, in der dortigen Spec stand %Length als Datentyp für width und height.
Wichtig ist: width="1024px"
ist trotzdem falsch. Der Attributwert darf nur eine Zahl sein. Die Einheit px wird vorausgesetzt und nicht angegeben. Richtig ist width="1024"
. Der Browser akzeptiert 1024px scheinbar trotzdem, aber nur, weil er beim ersten Zeichen, das keine Ziffer (oder ein Prozentzeichen) ist, aufhört zu lesen. Dass er Einheiten nicht beachtet, merkst Du, wenn Du statt 500px 500em hinschreibst. Das Ergebnis bleibt unverändert. Aus historischen Gründen wird nur das % beachtet.
In der HTML 5 Spec ist es etwas merkwürdig. Einerseits steht da in §4.7.20, dass width und height als Dimensionsattribute vorzeichenlose Integers sein müssen. Andererseits hat img eine riesige Beschreibung dessen, was beim Update eines srcset passieren muss, da wird ebenfalls auf das width Attribut des img Elements Bezug genommen, und da steht dann, dass auch ein Prozentwert erlaubt ist. Yikes!
Wie auch immer, zumindest Chrome akzeptiert beim iframe eine width-Angabe in % (noch?), aber der HTML Validator des W3C weist es als falsch zurück. Man sollte es unterlassen.
Es wird auch kein style= akzeptiert und schon gar kein class= oder id=.
Da hast Du Dich ins Bockshorn jagen lassen. Der iframe unterstützt die 14 Universalattribute. Die werden aber nur anzeigt, wenn man auf den Link klickt (der eher ein Button sein sollte, aber auf Mediawiki haben wir nicht so viel Einfluss). class
, id
und style
sind immer verfügbar.
Im Style-Attribut (oder in einer CSS Regel) kannst Du die Breite in allen gewünschten Einheiten angeben, und hier musst Du auch eine Einheit angeben. width: 1024;
im Style ist falsch und würde ignoriert. Du kannst im Style auch rechnen (mit calc()
), Min/Max-Werte angeben (min()
, max()
, clamp()
) oder custom attributes (salopp CSS Variablen genannt) verwenden.
Wenn Du width als Attribut und als CSS Eigenschaft angibst, hat das CSS übrigens Vorrang.
Rolf
Hallo Rolf B,
wenn du uns schon Siezt, dann schreib die Anrede „Ihr“ wenigstens groß 😉. Beim „Du“ darf man heutzutage klein schreiben (ich tu das nicht), und das Du ist hier im Forum üblich.
Und auch das „ihr“ wäre keine Höflichkeitsanrede 😉. Aber du meinst „… in Ihrem Beispiel …“
Bis demnächst
Matthias
Hallo Matthias,
wenn du uns schon Siezt, dann schreib die Anrede „Ihr“ wenigstens groß 😉. Beim „Du“ darf man heutzutage klein schreiben (ich tu das nicht), und das Du ist hier im Forum üblich.
Und auch das „ihr“ wäre keine Höflichkeitsanrede 😉. Aber du meinst „… in Ihrem Beispiel …“
Bist Du da sicher?
„Sehr geehrter Herr Apsel, Ihr Beitrag weist einen Irrtum auf 😜.“
Ich meinte übrigens „… in ihren Beispiel …“, wollte den Typo am Ende aber ignorieren.
Rolf
Hallo Rolf,
Bist Du da sicher?
„Sehr geehrter Herr Apsel, Ihr Beitrag weist einen Irrtum auf 😜.“
Ich meinte übrigens „… in ihren Beispiel …“, wollte den Typo am Ende aber ignorieren.
Da sieht man mal wieder wie verkompliziert die deutsche Sprache ist. Die hätten bei der letzen Reform besser sowas abgeschafft, anstatt die unsinnigen Änderungen.
Bin aber auch noch nicht sicher, ob du da richtig liegst. Weil, es ist ja schon mal kein Brief hier und die Sachen, die ich fand, könnten auch anders gedeutet werden:
https://www.schreibwerkstatt.co.at/2012/07/16/ihr-oder-ihr/
https://www.duden.de/sprachwissen/sprachratgeber/Gross-oder-Kleinschreibung-von-duDu-und-ihrIhr
Aber offfen gesagt ich habe selbst oft das Problem, nicht zu wissen wann ich sowas gross/klein (ausserhalb vom Brief) schreibe, daher mal interessant zu wissen.
Gruss
Henry
Hallo
https://www.schreibwerkstatt.co.at/2012/07/16/ihr-oder-ihr/
Haha, „ihr-oder-ihr“. Da fällt mir „You can say you to me.“ ein. 😆
Aber offfen gesagt ich habe selbst oft das Problem, nicht zu wissen wann ich sowas gross/klein (ausserhalb vom Brief) schreibe, daher mal interessant zu wissen.
Hmm, als direkte Anrede groß, sonst klein. So habe ich das gelernt.
Tschö, Auge
Liebes Auge,
Da fällt mir „You can say you to me.“ ein. 😆
you may say thou to me and I will do the same to thee.
Liebe Grüße
Felix Riesterer
Hallo,
Aber offfen gesagt ich habe selbst oft das Problem, nicht zu wissen wann ich sowas gross/klein (ausserhalb vom Brief) schreibe, daher mal interessant zu wissen.
dabei ist es gar nicht so kompliziert: Die förmliche Anrede "Sie" in der Höflichkeitsform sowie alle deklinierten Formen davon ("von Ihnen bestätigt", "nach Ihren Vorgaben") werden groß geschrieben.
Die persönliche, informelle Anrede "du" (und die deklinierten Formen) werden nach der Rechtschreibreform in der Regel klein geschrieben, dürfen aber als Ausdruck des Respekts auch weiterhin groß geschrieben werden.
Live long and pros healthy,
Martin
Hallo Henry,
es ist ja auch kompliziert. Diese blöden Pronomen heißen alle gleich und bedeuten ständig was anderes.
Hallo Henry, würdest du/Du bitte das Wiki updaten?
⇒ informelle Anrede einer Einzelperson, 2. Person Singular, klein oder groß
Herr Müller, würden Sie bitte das Wiki updaten?
⇒ formelle Anrede einer Einzelperson, 3. Person Nominativ Plural(ins Volk übergegangener Pluralis Majestatis), definitiv groß
Minna, würde Sie bitte das Wiki updaten?
⇒ formelle Anrede einer Einzelperson, 3. Person weiblich Singular, antiquiert, auch groß
Liebe Kolleginnen und Kollegen, würden Sie bitte das Wiki updaten?
⇒ formelle Anrede einer Gruppe in der 3. Person Plural, groß
Schau mal, sie updatet / sie updaten das Wiki! ⇒ keine Anrede, nur ein Pronomen (mir unbekannten Typs) in 3. Person Singular weiblich / Plural, klein
Sehr geehrte Frau Kollegin, Ihr Wiki-Artikel braucht ein Update
⇒ formelle Anrede einer Einzelperson, 3. Person Genitiv Plural, alternativlos groß
Sehr geehrte Kolleginnen und Kollegen, Ihr Wiki-Artikel braucht ein Update
⇒ Höflichkeitsform des Possesivpronomens der 2. Person Plural, alternativlos groß
Hallo Forum, ihr müsst eure Wiki-Artikel updaten ⇒ informelle Anrede einer Gruppe, 2. Person Nominativ und Genitiv, Plural, klein oder groß
Hallo Forum, eure/Eure Wiki-Artikel brauchen ein Update
⇒ informelles Possesivpronomen im Plural, klein oder groß
Wenn Euer Hochwürden bitte den Wiki-Artikel exorzieren würden?
⇒ Formelle Anrede, immer groß
Nein, das ist nicht ihr Kind ⇒ keine Anrede. Possesivpronomen im Genitiv, Singular weiblich (die Mutter) oder Plural (die Eltern)
Eigentlich ist die Merkregel gar nicht schwer: Höfliche oder formelle Anreden immer groß, sonst klein. Dass ich immer noch „Du“ schreibe, ist veraltet, aber es ist mir nun mal so eingebrannt worden. Jemanden mit „sie“ anzureden war schon immer ein Fehler.
Rolf
@@Rolf B
Jemanden mit „sie“ anzureden war schon immer ein Fehler.
Es sei dir gestattet, mich mit „Er“ anzureden.
😷 LLAP
Hallo,
Jemanden mit „sie“ anzureden war schon immer ein Fehler.
Es sei dir gestattet, mich mit „Er“ anzureden.
das erinnert mich an einen ehemaligen Kollegen, schon viele Jahre her. Andi hatte ein eher schlichtes Gemüt, war aber eine Seele von Mensch, und in seiner eigentlichen Aufgabe (primär Aufbau und Verdrahtung von Schaltschränken) gut und zuverlässig.
Andi war es gewöhnt, dass jeder ihn duzte, und ich habe ein paarmal erlebt, dass er, wenn er gesiezt wurde, widersprach: "I bin net sie, i bin er."
Derselbe Andi wurde auch ab und zu gebeten, für uns Softwerker kleine Krücken zu bauen. Zum Beispiel spezielle Adapterkabel. Stecker Typ X auf Stecker oder Buchse Typ Y, bestimmte Pinbelegung und -verbindung nach Skizze. Dann sah er sich die Skizze meistens einen Moment ratlos an und fragte dann: "Hasch mir net vielleicht a Muschter zum Nachbaua?"
Im Nachbauen war er dann auch wieder sehr zuverlässig - was er dann ablieferte, funktionierte meist auf Anhieb. Aber nach Skizze arbeiten war nicht so seine Stärke. Obwohl er seine Schaltschränke in aller Regel auch nach einem Verdrahtungsplan aufbauen musste, den ein anderer Kollege erstellt hatte ...
Live long and pros healthy,
Martin
@@Rolf B
Im Style-Attribut (oder in einer CSS Regel) kannst Du die Breite in allen gewünschten Einheiten angeben, und hier musst Du auch eine Einheit angeben.
width: 1024;
im Style ist falsch
Bis hierhin stimmt’s (fast – es sollte „in allen gewünschten Längeneinheiten“ heißen).
und würde ignoriert.
Hier wollte ich einwerfen „Moment mal!“
Bei der CSSBattle kann man bei etlichen Eigenschaften reine Zahlenwerte angeben, um Zeichen zu sparen – u.a. bei margin
, padding
, width
, height
.
Und so werfe ich ein „Moment mal!“
Im Standardmodus (d.h. mit <!DOCTYPE html>
) werden reine Zahlenwerte ignoriert. Test: nichts zu sehen
Im Quirksmodus hingegen werden reine Zahlenwerte als px
interpretiert. Test: was zu sehen
😷 LLAP
Nachtrag: Das soll jetzt natürlich keine Motivation sein, den Quirksmodus zu verwenden.
Hallo Gunnar,
Bei der CSSBattle kann man …
wie funktioniert das dort. Weil, ich sehe zwar die Sachen dort aber nicht das jeweils dazugehörige CSS. Ist das so gewollt oder finde ich das nicht?
Gruss
Henry
Hallo Henry,
wie funktioniert das dort. Weil, ich sehe zwar die Sachen dort aber nicht das jeweils dazugehörige CSS. Ist das so gewollt oder finde ich das nicht?
Es handelt sich um einen Wettbewerb, das CSS (und auch das HTML) zu erstellen, ist deine Aufgabe. Wer die wenigsten Zeichen benötigt, hält den Rekord. Deshalb siehst du natürlich erstmal keine Lösungen.
Bis demnächst
Matthias
Hallo Rolf B - und an Alle, die Ideen dazu beitragen,
Du hast natürlich recht, dass man in HTML das px nicht angeben muss/soll, Du hast aber unrecht, dass CSS funktioniert. Das tut es nämlich nicht. Ich habe das in allen Varianten ganz systematisch ausprobiert. Es wird dann nichts angezeigt.Auch calc funktioniert dann logischerweise nicht. Es wird nur pures html und die Parameter lt. Definition wie in w3schools.com unter iframe dargestellt, akzeptiert Wenn man hingegen % in reiner HTML-Notation angibt, wird das iframe zwar angezeigt aber eben nur in der voreingestellten Größe vom 300px Breite und 150px Höhe. Das ist anfangs auch etwas irritierend.
Ich sehe schon, dass es nicht ohne Javascript geht aber hier stehe ich vor dem Problem das Ergebnis aus Javascript zwischen die Anführungszeichen zu kriegen. Das geht nämlich auch nicht. Ich sehe nur den Umweg über PHP. Dann funktioniert es wenigstens auf den Folgeseiten, die ebenfalls PHP benötigen. Der Aufwand hält sich wenigstens in Grenzen.
Ich finde iframe nach wie vor stiefmütterlich behandelt obwohl es eine sehr elegante Lösung für Steuerelemente darstellt. - Beispiel: die Fotos-App beim iPhone mit dem Bild oben und den Vorschaustreifen unten, die unabhängig voneinander verschoben werden können und mit Tip auf ein Vorschaubild unten wird das Bild oben vergrößert dargestellt. Vergrößert man dann das Bild durch Aufziehen werden die Vorschaubilder nicht aus dem Anzeigebereich gedrängt. Ich stieß auf das Problem, weil ich eine ähnlich aufgebaute Galerie präsentieren will. Man könnte damit auch auf mobilen Geräten wunderbar ein dauerhaft sichtbares Menü darstellen, das beim Scrollen an Ort und Stelle bleibt. Das ist m-E. intuitiver als 3 Streifen oben als Platzhalter für ein Kontextmenü. Für viele ältere Menschen sind die 3 Streifen nichtssagend.
Soviel dazu. Wenn noch ein paar mit guten Ideen sich melden - gerne und Danke
Herbert
Hallo,
… Du hast aber unrecht, dass CSS funktioniert. Das tut es nämlich nicht. Ich habe das in allen Varianten ganz systematisch ausprobiert. Es wird dann nichts angezeigt.Auch calc funktioniert dann logischerweise nicht.
kannst du mal deine Testseite hochladen? Denn bei mir können auch iFrames mit css gestaltet werden.
Gruß
Jürgen
Hallo Jürgen,
ich habe das Problem mittlerweile gelöst - mit Javascript und PHP. Das Ganze ist ziemlich schlank und ist auch für den Generatorbetrieb gut geeignet - Informationen zu den einzelnen Elementen der Galerie und Darstellungsparameter die bildspezifisch angepasst/aufbereitet werden, wie Text im Bild u.a. werden neben den Inhaltsverzeichnissen der Bilder und Vorschaubilder, die damit verknüpft sind, in einer MySQL-Datenbank erfasst und bereit gehalten. Das ist allerdings noch zu bewerkstelligen.
Was allerdings noch etwas stört: Die Vorschau zeigt beim Laden eines Bildes bzw. der Seite dazu immer den Anfang anstatt dass das gewählte Bild oben mit einem Rahmen markiert in der Vorschau unten im iFrame in der Mitte erscheint, wie es Apple in der Fotos-App realisiert hat. Hier wäre ich für Anregungen dankbar.
Hier zur Anschauung die Seite: http://d-lobo.de
Edit Rolf B: Link erzeugt
Gruß Herbert
Hallo HP,
ich habe das Problem mittlerweile gelöst - mit Javascript und PHP
Oh je. Da hast Du noch eine lange und steile Lernkurve vor Dir.
Lass dein HTML mal über einen HTML Validator laufen. Da sind unpaarige Anführungszeichen, und ein <link> Element zum Laden eines Stylesheets gehört nicht nach <style></style> hinein. Innerhalb von <style></style> stehen nur CSS Regeln. Das kann ein Grund sein, warum dein CSS nicht gewirkt hat. Wobei ich dein mystyle.css auch nicht recht verstehe. Für jedes Vollbild eigene Style-Regeln haben zu wollen, huh, das ist umständlich. Das erschwert eine generische Lösung etwas.
Lerne Flexbox und Grid kennen. Tables zum Seitenlayout sind seit über 10 Jahren ein Anti-Pattern. Bei Grid muss man im Internet Explorer etwas aufpassen - sofern man den noch beachten will - Flexbox ist überhaupt kein Problem.
Deine CSS Probleme mit dem iframe können auch am Table-Layout liegen. Wenn Du nur den iframe gestyled hast, passiert nichts. Die Table muss ebenfalls width:100% bekommen. Und schon ist der Fall erledigt. Hättest Du, wie erbeten, vorher mal deine Seite präsentiert, dann hätte man sich das anschauen können.
Eine CSS Angabe "align:center" gibt es nicht. Es gibt ein Attribut align am table Element, dem Du "center" geben kannst. Die Zentrierung einer Table in ihrem Elternelement (z.B. dem body) per CSS geht mit margin:auto
.
Statt der Einzellen-Table (was nützt das überhaupt?) mit dem iframe wäre generell ein nav Element mit einer Thumbnail-Liste darin sinnvoller. Das PHP dazu kannst Du includen, falls Du die Galerie anderswo wiederverwenden willst.
<nav class="galerie">
<ul>
<li>
<a href="/galerie.php?bild=1" data-bild="1">
<img src="thumbnails/01roczeich.jpg" alt="Das Wort singt die Welt">
</a>
</li>
<li>
<a href="/galerie.php?bild=2" data-bild="2">
<img src="thumbnails/02samkh3.jpg" alt="Samkhya-Yoga Buch">
</a>
</li>
...
</ul>
</nav>
Die data-Attribute braucht man für die einfachere JavaScript-Unterstützung der Galerie, ansonsten sind sie unnötig.
Als CSS nimmst Du
.galerie {
width: 90vw; /* schmaler Bildschirm: 90% der Breite */
max-width: 80em; /* zu breiter Bildschirm: auf 80em limitieren */
margin: auto;
}
.galerie ul {
width: 100%;
height: 7em; /* zum Beispiel */
display:flex;
overflow-x:scroll;
list-style: none;
}
.galerie img {
border: 3px solid yellow;
height: 6em;
}
Größenangaben in em beziehen sich auf den Font, der an dieser Stelle gilt. Bei einem Font mit font-size:16px ist 1em = 16px. Wählt der User eine Vergrößerung im Browser aus, ändert der Browser die Fontsize. Alles, was in em angegeben ist, skaliert dann mit. So macht man das heute.
Die Flexbox sorgt dafür, dass die Listenelemente alle nebeneinander kommen. Mit overflow-x:scroll wird das alles horizontal scrollbar.
HTML und CSS sind jetzt aus der Hüfte geschossen und nicht ausprobiert. Vielleicht muss man noch etwas daran herumzupfen.
Die li Zeilen generierst Du im PHP aus deiner DB. galerie.php entspricht deinen jetztigen Pages, aber statt der hartcodierten Bildnummer nimmst Du sie aus $_GET["bild"]
.
Natürlich löst auch dieses Design nach einem Klick einen Rücksprung der Thumbnail-Liste auf Position 1 aus. Den kannst Du aber nicht wirklich verhindern. Man könnte alle Vollbilder übereinander auf die Seite legen und mittels :target Selektor im CSS dafür sorgen, dass nur das gerade ausgewählte Bild sichtbar ist. Das löst aber eine Datenflut aus, weil einige Browser dann sämtliche Bilder vorab laden könnten. Besser ist da eine JS Lösung.
Man fügt dafür der Galerie einen click-Handler hinzu, der click-Events auf die a Elemente abfängt und das Bild austauscht.
document.querySelector(".galerie").addEventListener("click", function(clickEvent) {
if (!clickEvent.target.href) return; // Kein Klick auf ein a Element
let bild = clickEvent.target.dataset.bild; // Liest data-bild aus dem a-Element
// Hier das Vollbild aktualisieren
clickEvent.preventDefault(); // Verhindern, dass der Browser dem Link folgt.
});
Das ist erstmal nur das Grundgerüst, das Klicks auf a Elemente in der Galerie erkennt und die Bildnummer ausliest. Statt data-bild könnte man auch das href-Attribut des Links auslesen und die Bildnummer herausinterpretieren - aber mit dem dataset ist es doch deutlich einfacher. Allerdings erst ab Internet Explorer 11 - wenn Du ältere IE unterstützen willst, nimm statt dataset.bild
lieber getAttribute("data-bild")
.
Wie dieses Script an die Daten für das Vollbild kommt (URL und Meta-Informationen), das kann man unterschiedlich gestalten. Entweder mit einem AJAX-Aufruf, der die Daten oder ein HTML Fragment für das Vollbild liefert, oder du codierst die Informationen in data-Attributen der Galerie-Links, oder Du generierst im PHP ein Stück Script, das diese Daten enthält. Geht alles. Wo willst Du hin?
Rolf
Vielen Dank Rolf,
für die ausführliche Analyse und der Anregung zur Verbesserung. Das geladene CSS mystyle.css ist ein Relikt und nicht mehr vonnöten. Es stammt von einer (Lehrerin) Schülerin in HTML und CSS. Ich habe da ausschließlich lokale Styles verwendet, die dann, bis auf die seitenspezifisch im PHP manipulierten/angepassten Styles, im Rahmen der Weiterentwicklung in ein globales CSS überführt werden. Das ist jetzt mal eine leidlich funktionierende Rohfassung, der mit heißer Nadel gestrickten Seite.
Ich bin da jetzt mit 72 nach wie vor lernwillig und fähig, und steil - da halte ich es mit den bayrischen Wahlspruch: Und ist der Berg auch noch so steil, ein bisserl was geht alleweil ;-)
Was in der Rohfassung noch fehlt, habe ich ja erklärt - ich will die gewählte und markierte Vorschau im iframe mittig unter dem großen Bild der Seite sehen und nicht erst im iframe blättern müssen, wo ich mich gerade befinde. Hernach wird dann die Seite noch mal richtig vorgenommen und von Unsauberkeiten und Überflüssigem befreit, bevor dann die Generatorgeschichte in PHP umgesetzt wird.
Herbert
Hallo HP,
ich will die gewählte und markierte Vorschau im iframe..
quieeeetsch Moment mal.
Willst Du wirklich den iframe? Ich habe doch gezeigt, dass es auch ohne iframe geht. Ein iframe macht es wirklich nicht einfacher.
Nur in einem Aspekt (aber das hab ich nicht ausprobiert):
Wenn die page47.php die Galerie als iframe einbindet, dann könntest Du aus dem PHP heraus die URL als vorschau.php#bild17 angeben. Wenn das HTML Element mit dem Vorschaubild Nr. 17 ein ID-Attribut (id="bild17"
) hat, würde der Browser dafür sorgen, dass dieses Element sichtbar wird. Was Du trotzdem nicht verhindern kannst, ist, dass sich die Galerie ggf. repositioniert. Wenn das Vorschaubild vor der Auswahl irgendwo in der Mitte war, ist es nachher (vermutlich) links am Rand, weil sich der Browser nichts von der vorigen Seite merkt. Wenn Du das lösen willst, brauchst Du einen Klick-Handler mit JavaScript.
Rolf
Hallo Rolf,
ok. Ich werde da Einiges von Deinen Vorschlägen studieren und ausprobieren - probieren geht über studieren. Ich bin immer an eleganten Lösungen interessiert und bei Webseiten gilt für mich: Der Betrachter steht im Vordergrund. Ihm muß es möglich sein, seiner Intuition zu folgen und das möglichst einfach und er soll immer wissen, wo er sich gerade befindet. Deshalb hatte ich ja links oben - Seite von Seiten angezeigt und mit der markierten Vorschau sollte der Benutzer auch die bildliche Orientierung erhalten. M.E. wird ein Webauftritt (hier speziell eine Galerie) dann am besten angenommen, wenn der Betrachter es wie in einer physischen Bildergalerie halten kann - frei zu entscheiden, welche Bilder, in welcher Reihenfolge er wie lange betrachten will und wie er zu weiteren Informationen zu den Bildern, den Verfasser und dessen Intention kommt, ohne die Orientierung zu verlieren.
Herbert
Hallo Herbert,
Ich bin immer an eleganten Lösungen interessiert und bei Webseiten gilt für mich: Der Betrachter steht im Vordergrund. Ihm muß es möglich sein, seiner Intuition zu folgen und das möglichst einfach und er soll immer wissen, wo er sich gerade befindet.
das ist ein lobenswerter Standpunkt - aber auch ein schwieriger. Denn Nutzer nehmen die Navigations- und Bedienungselemente sehr unterschiedlich wahr.
Beispiel: Die Baumansicht der Verzeichnishierarchie im Windows-Explorer. Ich kenne einige Nutzer, die sagen, sie könnten damit nichts anfangen, das verwirre sie nur. Für mich dagegen ist es das wichtigste Navigationselement überhaupt, das A und O, nicht wegzudenken. Deshalb konnte ich mich mit Dateimanagern im Norton-Commander-Stil (Inhalte von zwei Verzeichnissen nebeneinander) auch nie so richtig anfreunden.
Menschen empfinden unterschiedlich und setzen unterschiedliche Schwerpunkte. Du wirst es daher nie schaffen, es allen recht zu machen - die Absicht ist löblich, das Ziel aber unerreichbar.
M.E. wird ein Webauftritt (hier speziell eine Galerie) dann am besten angenommen, wenn der Betrachter es wie in einer physischen Bildergalerie halten kann
Etwas nachzubilden, was die Besucher aus dem wirklichen Leben kennen, kann eine gute Idee sein; oft liegt der Reiz aber auch gerade darin, Neues zu probieren.
frei zu entscheiden, welche Bilder, in welcher Reihenfolge er wie lange betrachten will und wie er zu weiteren Informationen zu den Bildern, den Verfasser und dessen Intention kommt, ohne die Orientierung zu verlieren.
Auf jeden Fall. Deswegen mag ich auch Bildergalerien nicht, bei denen ich nur streng sequentiell ein Bild nach dem anderen anschauen kann - in der Reihenfolge, die der Autor/Künstler/Fotograf vorgegeben hat.
Live long and pros healthy,
Martin
Hallo Der,
Auf jeden Fall. Deswegen mag ich auch Bildergalerien nicht, bei denen ich nur streng sequentiell ein Bild nach dem anderen anschauen kann - in der Reihenfolge, die der Autor/Künstler/Fotograf vorgegeben hat.
ich mag das auch nicht, ist aber kurioserweise das milliardenschwere Erfolgsgeheimnis von Instagram.
Gruss
Henry
@@HP
bei Webseiten gilt für mich: Der Betrachter steht im Vordergrund. Ihm muß es möglich sein, seiner Intuition zu folgen und das möglichst einfach und er soll immer wissen, wo er sich gerade befindet.
👍 Löblich.
M.E. wird ein Webauftritt (hier speziell eine Galerie) dann am besten angenommen …
Hier könnte es problematisch werden. Besser Nutzertests als unverifizierte eigene Annahmen.
😷 LLAP
Hallo Hp,
Ich sehe schon, dass es nicht ohne Javascript geht aber hier stehe ich vor dem Problem das Ergebnis aus Javascript zwischen die Anführungszeichen zu kriegen. Das geht nämlich auch nicht.
Doch, es geht auch bei mir. Versuchst Du mit CSS, das innerhalb des iframe geladen wird, den iframe selbst zu beeinflussen? Das kann nicht gehen.
Mit JS kannst du aus dem iframe hinausgreifen, sofern iframe-Inhalt und einbettende Seite den gleichen Origin[1] haben. Dann kommst Du im iframe mit window.parent.document
an das Dokument des parent-Dokuments heran. Aber ich würde mal sagen: Sowas sollte man vermeiden, wenn es anders geht.
... Galerie ...
Um zu vermeiden, dass sich HTML Elemente gegenseitig stören, brauchst Du nicht zwingend iframe-Konstrukte. Das geht auch auf einer Seite. Literaturhinweise wären hier: CSS Grid für das Seitenlayout, overflow:scroll für einen div-Inhalt der sich scrollen lässt und position:absolute für Popups. Unser Wiki hat da auch was.
Rolf
Der Origin wird durch Schema (http/https), Hostname und Port festgelegt. Alle drei müssen übereinstimmen, damit zwei URL als "same origin" aufgefasst werden. ↩︎
Hallo Rolf,
die Positionierung per Scrollen, so dass das, zur Orientierung markierte Vorschaubild unter dem angezeigten Bild zu stehen kommt, habe ich realisiert. Es waren nur ein paar wenige Zeilen PHP-Code und die von PHP präparierten und generierten Javascript Codezeilen. Die Vorschaubilder am Anfang und am Ende kommen so nicht direkt unter dem Bild zu stehen aber dafür ist die Übersicht größer. Wichtig war, dass sie immer sichtbar sind. Lediglich auf Mobilgeräten klappt es noch nicht aber auch da sollte es ohne großem Aufwand möglich sein.
Herbert
Hallo Herbert,
Um deine Eingangsfrage nochmal aufzugreifen:
Wie also könnte das Problem gelöst werden?
Antwort: Durch ein völliges Neuschreiben der Seite.
Schau Dir den Netzwerktrace deiner Seite an, und dann sag mir, ob Du damit wirklich zufrieden bist.
Deine getWidth-Funktion lädt die Seite neu, sobald ein Resize stattfindet. Ein Klick auf bspw. Seite 24 lädt:
background-color: #F8B469;
???)Das meiste kommt bei mir aus dem Memory-Cache des Browsers, aber nach jedem Resize einen vollen Page-Reload??? Um Himmels Willen! Ein langsames Gerät geht dabei schwer in die Knie. Gerade bei Mobilgeräten ist das der Fall.
Ich habe Dir diverse Hinweise gegeben, wo Du ansetzen musst, damit der iframe auf CSS hört. Ich habe Dir auch erklärt, dass ein iframe für die Vorschau komplett unnötig ist. Aber das ignorierst Du. Statt dessen verwendest Du eine für Client und Server schwer belastende "reload on resize" Logik.
Das geht definitiv deutlich besser.
Rolf
Hallo Rolf,
mir ging es erst mal darum, dass das Vorhaben in allen Punkten grundsätzlich umsetzbar ist. Als nächstes kommt dann die Optimierungsphase, da wird alles auf den Prüfstand gestellt und da kommen auch Methoden zum Einsatz, die besser geeignet sind - unter der Voraussetzung, dass die Funktion erhalten bleibt. Ich bin da völlig pragmatisch und verschließe mich keiner Methode, die einfacher eleganter zum Ziel führt. Darauf folgt dann die Umsetzung für den Generator, nach gleichen Prinzip
Danke für deine Vorschläge und Hinweise, sie werden ihren Niederschlag finden.
Aber in einem Fall verstehe ich dich nicht - iframe ist auch ein durchaus elegantes Feature um ohne Eingriffe in ein bestehendes Seitenkonzept eine fremde Quelle einzubinden und dazu kann man die fremden Inhalte in den Berechtigungen so steuern, dass sie in einer Sandbox laufen. Alle anderen Möglichkeiten bieten das nicht.
Genauso finde ich es falsch, die Tabellen in HTML zu verteufeln. Die Tabellen sind eine gute Möglichkeit, mit geringstem Aufwand aus Excel-Daten eine Webumsetzung zu erreichen, die sogar bessere Flexibilität als Excel bietet.
Dogmen sind immer fragwürdig und meist nur ein Ausdruck eingeschränkte Expertise zu verteidigen. Für mich gilt ein gut gefüllter Werkzeugkasten als Basis für gute Arbeit und kein Werkzeug ist überflüssig. Es ist nur wichtig zu lernen und zu wissen wann welches am besten zum Einsatz kommt. Dazu zählt für mich das ökonomische Prinzip - oder moderner: "keep it simple stupid" Die Wartbarkeit dankt es Einem.
Hallo HP,
Genauso finde ich es falsch, die Tabellen in HTML zu verteufeln. Die Tabellen sind eine gute Möglichkeit, mit geringstem Aufwand aus Excel-Daten eine Webumsetzung zu erreichen, die sogar bessere Flexibilität als Excel bietet.
Genau dafür sind Tabellen ja auch da; zur Darstellung tabellarischer Daten. Sie sollten nicht verwendet werden, um eine Seite in einem Raster darzustellen.
Bis demnächst
Matthias
@@HP
mir ging es erst mal darum, dass das Vorhaben in allen Punkten grundsätzlich umsetzbar ist. Als nächstes kommt dann die Optimierungsphase
Einreißen und Neubauen (weil die Implementierung vom Grundkonzept her schon falsch ist) ist keine Optimierung, sondern eben ein Neubau.
Einen solchen möchte man möglichst vermeiden (weil aufwendig), indem man von Anfang an eine geeignete Basis zugrundelegt.
Genauso finde ich es falsch, die Tabellen in HTML zu verteufeln. Die Tabellen sind eine gute Möglichkeit, mit geringstem Aufwand aus Excel-Daten eine Webumsetzung zu erreichen, die sogar bessere Flexibilität als Excel bietet.
Dogmen sind immer fragwürdig und meist nur ein Ausdruck eingeschränkte Expertise zu verteidigen.
Ich sehe in Rolfs Ausführungen keinerlei Dogmen. Im Gegenteil: eher gutwillige Formulierungen wie „Das geht definitiv deutlich besser“, was eine nette Umschreibung ist für – wie ich es gesagt hätte – „So wie du’s jetzt hast, das geht gar nicht.“
😷 LLAP
Hallo HP,
du argumentierst, als hätte ich Grundsatzdogmen aufgestellt. Aber ich habe lediglich deine Seite betrachtet. Ich habe mich nicht generell gegen Tables und Iframes ausgesprochen.
iframe ist auch ein durchaus elegantes Feature um ohne Eingriffe in ein bestehendes Seitenkonzept eine fremde Quelle einzubinden
Sicherlich. Aber das Schlüsselwort hier ist fremd. Wie fremd ist deine Vorschauliste?
und dazu kann man die fremden Inhalte in den Berechtigungen so steuern, dass sie in einer Sandbox laufen.
Paranoia ist nur echt, wenn Du Dich auch von Dir selbst verfolgt fühlst? Genau deswegen will ich Dir ja den iframe ausreden. Das ist kein Fremdinhalt. Die Vorschauliste ist integraler Teil deiner Galerie.
Früher™️ mal hat man Seiten als Frameset aufgebaut. Ein Frame für Navigation, einer für den Seitenkopf, einer für den Inhalt. Dein iframe verfolgt den gleichen Ansatz, aber davon ist man schon sehr lange abgekommen. Danach kamen die <table> Layouts, womit man die vermeintliche Einfachheit retten wollte, mit der ein Frame eine Seite in Zonen einteilt (und weil es damals nichts anderes gab). Mittlerweile gibt es Flexbox, was für Seitenlayout melioral (Hä?) ist, und Grid, was optimal wäre, wenn Subgrids endlich auch in Chrome ankämen. Beide Features haben die Eigenschaft, dass Du damit das Seitenlayout von links auf rechts drehen kannst, wenn sich die Breite des Viewports (=Fenster/Bildschirm) ändert. Welche Bocksprünge Du zur Zeit dafür treiben musst, haben wir schon durchgekaut.
Genauso finde ich es falsch, die Tabellen in HTML zu verteufeln.
Amen.
Die Tabellen sind eine gute Möglichkeit, mit geringstem Aufwand aus Excel-Daten eine Webumsetzung zu erreichen
Amen.
Und nun guck Dir Deine Seite an und sag mir, wo die tabellarischen Daten sind, die man sinnvoll in Excel darstellen könnte. Und ich rede nicht vom generischen „Universaldokument“ Einsatz, den Excel in den meisten Verwaltungen findet. Sag mir, wo der Nutzen einer Tabelle mit einer Zeile und einer Spalte ist. Es gab mal Zeiten, da hat man so Inhalte auf der Seite zentriert. Aber es gibt mittlerweile nur noch eins, was wir dem Gott des Todesable Layouts sagen: „Nicht heute.“
Rolf