Menü-Bar ohne CSS und Javascript möglich?

[Jens Funkenberger]

Hallo Liebe Kolleginnen und Kollegen,

Ich habe eine eher ungewöhnliche Frage. Als Backend Developer habe ich sonst nur minimal mit Frontend zu tun, leider komme ich nun nicht umhin. Ich muss einen internen Auftritt für meine Abteilung gestalten und wollte hierzu CSS/JS und HTML zur Hilfe nehmen, nur um dann festzustellen, dass alle relevanten Tags gesperrt wurden (<script>, <style>…). Das laden einer externen CSS Datei funktioniert auch nicht.
Meine Frage:

Wie kann ich mit reinem HTML eine halbwegs ansprechende Menü-Bar erstellen. Diese soll Elemente (Bilder) enthalten und jeweils Text im Body der Seite laden bei klick. Ich dachte da an einfache Links, weiß ich nicht wie ich ohne CSS oder JS den Content entsprechend anpassen kann. Wäre dankbar für Tipps.

Beste Grüße,

Jens

[Auge]

Hallo

Ich muss einen internen Auftritt für meine Abteilung gestalten und wollte hierzu CSS/JS und HTML zur Hilfe nehmen, nur um dann festzustellen, dass alle relevanten Tags gesperrt wurden (<script>, <style>…). Das laden einer externen CSS Datei funktioniert auch nicht.

Na schönen Dank auch. Dass aktive Inhalte ausgeschlossen werden sollen, kann ich ja noch nachvollziehen, aber CSS? Werden Bilder auch gesperrt?

Wie kann ich mit reinem HTML eine halbwegs ansprechende Menü-Bar erstellen. Diese soll Elemente (Bilder) enthalten und jeweils Text im Body der Seite laden bei klick.

Wenn der Inhalt im selben Dokument geladen, also kein neues Dokument angefordert werden soll, geht es nicht ohne CSS. Jedesmal ein neues Dokument zu laden, geht natürlich. Allerdings wird das Menü ohne CSS, genau so wie der ganze Rest der Seite, schmucklos aussehen.

Ich dachte da an einfache Links, weiß ich nicht wie ich ohne CSS oder JS den Content entsprechend anpassen kann.

Garnicht. Gehe deinem/n Admin(s) auf den Zünder, damit zumindest CSS erlaubt wird oder erstelle reine HTML-Seiten.

Tschö, Auge

[Jens Funkenberger]

Danke für Deine Hilfe! Das hatte ich schon befürchtet. Ich hatte gehofft, dass noch irgendwelche Tricks aus den Anfangszeiten existent sind. Die Anträge laufen schon. Offenbar verbieten die Konzernrichtlinien auch CSS -.-. Es ist echt zum Auswachsen.

Extern hat man alle Freiheiten intern geht überhaupt nichts.

[Camping_RIDER]

Aloha ;)

Danke für Deine Hilfe! Das hatte ich schon befürchtet. Ich hatte gehofft, dass noch irgendwelche Tricks aus den Anfangszeiten existent sind.

Naja. Du bestimmst über den doctype, welche HTML-Version du benutzt. Du kannst schon ein Frameset benutzen, wenn du den entsprechenden Doctype verwendest. Es ist also an dir, zu bestimmen, welche „Tricks aus den Anfangszeiten“ noch existieren. Allerdings...

Die Anträge laufen schon.

... ist es sinnvoller, die abzuwarten.

Offenbar verbieten die Konzernrichtlinien auch CSS -.-. Es ist echt zum Auswachsen.

Ich würde mal keinen bösen Willen, sondern einfach nur mangelnden Sachverstand unterstellen 😉

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Du bestimmst über den doctype, welche HTML-Version du benutzt.

Eher nicht. Welche Version du beim Verfassen des Quelltextes benutzst, ist irrelevant.

Relevant ist, welche Version der Parser (Browser) bei der Verarbeitung des Quelltextes benutzt. Und das ist (in aktuellen Browsern) immer HTML5 (wenn das Zeugs als text/html ausgeliefert wird). Browser haben nur einen HTML-Parser.

Mit der DOCTYPE-Angabe bestimmst du, welchen Rendermodus Browser fahren sollen: standard, almost standard oder quirks.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Relevant ist, welche Version der Parser (Browser) bei der Verarbeitung des Quelltextes benutzt. Und das ist (in aktuellen Browsern) immer HTML5 (wenn das Zeugs als text/html ausgeliefert wird). Browser haben nur einen HTML-Parser.

Das stimmt schon, aber Browser stellen ja HTML4-Frameset-Seiten auch immer noch korrekt dar 😉

Mit der DOCTYPE-Angabe bestimmst du, welchen Rendermodus Browser fahren sollen: standard, almost standard oder quirks.

Naja, in dem Fall ist es ja nicht nur der Rendermodus, oder wir haben unterschiedliche Abgrenzungsvorstellungen von „Rendermodus“.

Egal wie, wenn man ne Seite mit validem HTML4-Frameset schreibt kann man entsprechende obsolete Elemente verwenden und das ist dann sowohl valide als auch durch den Browser richtig dargestellt. Nur sonderlich sinnvoll ist es natürlich nicht, aber das sind die Rahmenbedingungen auch nicht.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Relevant ist, welche Version der Parser (Browser) bei der Verarbeitung des Quelltextes benutzt. Und das ist (in aktuellen Browsern) immer HTML5 (wenn das Zeugs als text/html ausgeliefert wird). Browser haben nur einen HTML-Parser.

Das stimmt schon, aber Browser stellen ja HTML4-Frameset-Seiten auch immer noch korrekt dar 😉

Natürlich tun sie das. Es wäre ja blöd, wenn Webseiten auf einmal nicht mehr funktionieren würden.

Die Sprachdefinition von HTML5 (wo es keine frameset/frame-Elemente mehr gibt) ist ja eher nur schmückendes Beiwerk.

Was HTML5 eigentlich definiert ist ein Parser, d.h. wie ein Parser den Quelltext zu verarbeiten hat. Und da gibt es für frameset natürlich nach wie vor Regeln.

<!DOCTYPE html>
<html>
	<head>
		<meta charset="UTF-8"/>
		<title>Frameset Test</title>
	</head>
	<frameset cols="*, *">
		<frame src="http://example.org"/>
		<frame src="http://example.org"/>
	</frameset>
</html>

wird problemlos verarbeitet.

Mit der DOCTYPE-Angabe bestimmst du, welchen Rendermodus Browser fahren sollen: standard, almost standard oder quirks.

Naja, in dem Fall ist es ja nicht nur der Rendermodus

Doch, genau das ist die einzige Funktion der DOCTYPE-Angabe.

oder wir haben unterschiedliche Abgrenzungsvorstellungen von „Rendermodus“.

Meine hatte ich genannt.

Egal wie, wenn man ne Seite mit validem HTML4-Frameset schreibt kann man entsprechende obsolete Elemente verwenden und das ist dann sowohl valide als auch durch den Browser richtig dargestellt.

Ja, ein Validator mag sich noch dafür interessieren, welche HTML-Version als Doctype angegeben ist; sofern man die HTML-Version, gegen die zu validieren ist, nicht explizit vorgibt.

Nur sonderlich sinnvoll ist es natürlich nicht

?? Wenn ich ein Frameset verwenden würde (wofür es vereinzelt sinnvolle Anwendungen geben kann), dann würde natürlich der Doctype HTML 4.01 Frameset bzw. XHTML 1.0 Frameset dafür sinnvoll sein.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Die Sprachdefinition von HTML5 (wo es keine frameset/frame-Elemente mehr gibt) ist ja eher nur schmückendes Beiwerk.

Was HTML5 eigentlich definiert ist ein Parser, d.h. wie ein Parser den Quelltext zu verarbeiten hat. Und da gibt es für frameset natürlich nach wie vor Regeln.

Das ist Definitionsfrage 😉 ich verstehe deinen Punkt, aber für mich ist die Sprachdefinition das Maß der Dinge und die Interpretation im Browser nachrangig, aber das kann man ja sehen wie man möchte.

<!DOCTYPE html>
<html>
	<head>
		<meta charset="UTF-8"/>
		<title>Frameset Test</title>
	</head>
	<frameset cols="*, *">
		<frame src="http://example.org"/>
		<frame src="http://example.org"/>
	</frameset>
</html>

wird problemlos verarbeitet.

Richtig. Ich habe aber mal gelernt, dass es meine Aufgabe als Entwickler ist, valides und sinnvolles HTML zu produzieren. Deshalb funktioniert dieser Code zwar, ist aber in meinen Augen falsch.

Mit der DOCTYPE-Angabe bestimmst du, welchen Rendermodus Browser fahren sollen: standard, almost standard oder quirks.

Naja, in dem Fall ist es ja nicht nur der Rendermodus

Doch, genau das ist die einzige Funktion der DOCTYPE-Angabe.

Funktion im Sinne der Wirkung im Browser ja, Sinn und Zweck nein. Sinn und Zweck der Doctype-Angabe ist eine Andere („an instruction that associates a particular SGML or XML document with a document type definition (DTD)“) und selbst wenn das in HTML 5 nicht mehr eindeutig gegeben ist, ist es das in HTML4.1/XHTML1 noch, und um diese Doctype-Angabe ging es ja.

Was der Browser damit tut und ob ihn das juckt oder nicht ist nachrangig, solange er das tut, was er soll, aber für das Dokument und seine Richtigkeit ist der Doctype schon relevant; und formale Richtigkeit ist grundsätzlich die optimale Voraussetzung, um in möglichst vielen Browsern das Dokument so interpretiert zu bekommen wie es gemeint ist.

Nur sonderlich sinnvoll ist es natürlich nicht

?? Wenn ich ein Frameset verwenden würde (wofür es vereinzelt sinnvolle Anwendungen geben kann), dann würde natürlich der Doctype HTML 4.01 Frameset bzw. XHTML 1.0 Frameset dafür sinnvoll sein.

Richtig.

By the way: Welche sinnvollen Anwendungen fallen dir da ein? Ich frage nicht weil ich zwangsläufig anderer Meinung bin, sondern eben weil mir spontan keine einfällt.

Grüße,

RIDER

[Felix Riesterer]

Lieber Camping_RIDER,

By the way: Welche sinnvollen Anwendungen fallen dir da ein? Ich frage nicht weil ich zwangsläufig anderer Meinung bin, sondern eben weil mir spontan keine einfällt.

eine offline-Doku. Wie die alten SELFHTML-Versionen mit ihrer Quick-Bar.

Liebe Grüße,

Felix Riesterer.

[Camping_RIDER]

Aloha ;)

By the way: Welche sinnvollen Anwendungen fallen dir da ein? Ich frage nicht weil ich zwangsläufig anderer Meinung bin, sondern eben weil mir spontan keine einfällt.

eine offline-Doku. Wie die alten SELFHTML-Versionen mit ihrer Quick-Bar.

Da wiegen meiner Meinung nach die Nachteile von Framesets schwerer als die Vorteile. Allen voran die Unmöglichkeit, Lesezeichen zu setzen.

Grüße,

RIDER

[Felix Riesterer]

Lieber Camping_RIDER,

Da wiegen meiner Meinung nach die Nachteile von Framesets schwerer als die Vorteile. Allen voran die Unmöglichkeit, Lesezeichen zu setzen.

man kann ein Lesezeichen innerhalb eines Framesets setzen. Moderne Browser schaffen das. Und bei einer offline-Doku darf man das Frameset auch mit JavaScript anreichern, um im Falle eines direkten Aufruf eines Teilframes das Frameset nachzuladen.

Liebe Grüße,

Felix Riesterer.

[Julius]

Hallo Felix,

Da wiegen meiner Meinung nach die Nachteile von Framesets schwerer als die Vorteile. Allen voran die Unmöglichkeit, Lesezeichen zu setzen.

Moderne Browser schaffen das.

Es will mir mit Firefox 51 nicht gelingen. Hast du eine Beispielseite, auf der es ging?

Gruß
Julius

[beatovich]

hallo
https://wiki.selfhtml.org/wiki/HTML/Frames

funktioniert bei mir tadellos.
Im Kontextmenu Aktueller Frame -> Lesezeichen setzen.

[Camping_RIDER]

Aloha ;)

Im Kontextmenu Aktueller Frame -> Lesezeichen setzen.

Gut, das war mir neu. Aber man muss da schon genau wissen was man braucht, wenn man ins Kontextmenü muss. Für 0815-Nutzer eher unpraktisch, imho. Aber immerhin gut, dass es geht. Wenigstens in Firefox.

Grüße,

RIDER

[Julius]

Hallo beatovich,

https://wiki.selfhtml.org/wiki/HTML/Frames

funktioniert bei mir tadellos. Im Kontextmenu Aktueller Frame -> Lesezeichen setzen.

Eben nicht:

• das Frameset „drumherum“ wird nicht wieder hergestellt (die Seite ist ohne Navigation unbrauchbar)
• der Nutzer muss den Button kennen, wie RIDER bereits schrieb und das der Durchschnittsnutzer weiß, was ein Frameset ist, bezweifle ich ebenfalls...

Ich verstand Felix’ Beitrag so, dass es mittlerweile eine bessere Lösung von Seiten der Browser gäbe: Der Browser speichert den Zustand des Framesets im Lesezeichen speichert und stellt ihn später wieder her.

Aber es ist schon verständlich, dieser 90er-Jahre-Technik beim Aussterben zuzugucken als sie noch zu fördern...

Gruß
Julius

[Camping_RIDER]

Aloha ;)

Moderne Browser schaffen das.

Mein Chrome 56 kann es nicht. Oder ich finde es nicht.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Die Sprachdefinition von HTML5 … ist ja eher nur schmückendes Beiwerk.

Was HTML5 eigentlich definiert ist ein Parser, d.h. wie ein Parser den Quelltext zu verarbeiten hat.

Das ist Definitionsfrage 😉 ich verstehe deinen Punkt, aber für mich ist die Sprachdefinition das Maß der Dinge und die Interpretation im Browser nachrangig, aber das kann man ja sehen wie man möchte.

Du hast mich nicht verstanden? Bei HTML5 ist die Interpretion durch einen Parser die Sprachdefinition, also das Maß aller Dinge.

Man kann eine Sprache ja über eine Grammatik definieren oder aber über eine Maschine, welche die Sprache erkennt (verarbeitet). Bis HTML 4.01 / XHTML 1.1 war ersteres der Fall: über eine Grammatik in Form der DTD (und die zugrundeliegenden Regeln von SGML bzw. XML).

Bei HTML5 ist man den anderen Weg gegangen. Ob mir oder dir das nun gefällt – es ist halt so. HTML5 wird nicht über eine Grammatik definiert, sondern über den Parser.

Ich habe aber mal gelernt, dass es meine Aufgabe als Entwickler ist, valides und sinnvolles HTML zu produzieren.

Wobei ich zweiteres über ersteres stellen würde.

Deshalb funktioniert dieser Code zwar, ist aber in meinen Augen falsch.

Deshalb würde ich ja auch einen Frameset-Doctype verwenden.

Doch, genau das ist die einzige Funktion der DOCTYPE-Angabe.

Funktion im Sinne der Wirkung im Browser ja, Sinn und Zweck nein.

Meine Rede im Folgeposting: „Die DOCTYPE-Angabe erfüllt also genau gar keine ihrer [ursprünglichen] Funktionen. Das einzige, wozu sie dient, ist als Schalter Quirksmodus aus/ein. Weil irgendwer in grauer Vergangenheit mal dachte, es wäre eine gute Idee, sie dazu zu missbrauchen.“

Sinn und Zweck der Doctype-Angabe ist eine Andere („an instruction that associates a particular SGML or XML document with a document type definition (DTD)“)

Es gab noch nie validierende HTML-Parser. Selbst in der XML-Welt sind validierende Parser wohl die Ausnahme.

und selbst wenn das in HTML 5 nicht mehr eindeutig gegeben ist

Nicht „nicht mehr eindeutig“, sondern: gar nicht. Im Sinne von: überhaupt nicht.

?? Wenn ich ein Frameset verwenden würde (wofür es vereinzelt sinnvolle Anwendungen geben kann) By the way: Welche sinnvollen Anwendungen fallen dir da ein? Ich frage nicht weil ich zwangsläufig anderer Meinung bin, sondern eben weil mir spontan keine einfällt.

Alle, wo es angebracht ist, zwei getrennte Dokumente nebeneinader (übereinander) im Browser ansehen zu können.

Ich will mir jetzt aber auch kein konkretes Beispiel dafür aus den Fingern saugen. ;-)

LLAP 🖖

[MudGuard]

Hi,

Es gab noch nie validierende HTML-Parser. Selbst in der XML-Welt sind validierende Parser wohl die Ausnahme.

ja, meistens reicht es, wohlgeformte Dokumente zu haben. Aber ich hab durchaus auch mit XML-Schnittstellen zu tun, die das übergebene XML gegen DTD oder Schema validieren.

cu,
Andreas a/k/a MudGuard

[Camping_RIDER]

Aloha ;)

Die Sprachdefinition von HTML5 … ist ja eher nur schmückendes Beiwerk.

Was HTML5 eigentlich definiert ist ein Parser, d.h. wie ein Parser den Quelltext zu verarbeiten hat.

Das ist Definitionsfrage 😉 ich verstehe deinen Punkt, aber für mich ist die Sprachdefinition das Maß der Dinge und die Interpretation im Browser nachrangig, aber das kann man ja sehen wie man möchte.

Du hast mich nicht verstanden? Bei HTML5 ist die Interpretion durch einen Parser die Sprachdefinition, also das Maß aller Dinge.

Haste Recht; aber ich sprach ja überhaupt nie vom HTML5-Doctype noch vom HTML5-definierenden Parser, auch wenn der nachher das korrekte HTML4.1-Dokument interpretieren soll. Ich hab dich schon verstanden, ich hab hier nur irgendwo sowas wie ein Henne-Ei-Problem, je nachdem auf welchen Standpunkt man sich stellt.

Stellt man sich auf den Standpunkt, auf dem ich stand (wir entwerfen ein valides HTML4.1-Dokument und wir dürfen da alles verwenden, was "damals" möglich war; der Browser wird es dann schon richtig interpretieren, weil muss ja), dann ist der Doctype und die Spezifikation als Sprachdefinition bedeutsam, weil es im Kern der Sache um HTML4.1 geht und weil man ja nicht weiß/wissen will, was der Browser genau tut; stellt man sich hingegen auf den Standpunkt, auf den du dich gestellt hast (der HTML5-Parser in den Browsern versteht alles mögliche, unter anderem Framesets), dann argumentiert man ja von HTML5 aus und dann ist der Doctype unwichtig und der Parser die Sprachdefinition.

Ich glaube wir haben einfach ein wenig aneinander vorbeigeredet.

Bei HTML5 ist man den anderen Weg gegangen. Ob mir oder dir das nun gefällt – es ist halt so. HTML5 wird nicht über eine Grammatik definiert, sondern über den Parser.

Danke für die Erinnerung; das hatte ich nicht mehr vollständig auf dem Schirm, auch wenn ich darüber ursprünglich wie gesagt über HTML5 gar keine Aussage treffen wollte.

?? Wenn ich ein Frameset verwenden würde (wofür es vereinzelt sinnvolle Anwendungen geben kann) By the way: Welche sinnvollen Anwendungen fallen dir da ein? Ich frage nicht weil ich zwangsläufig anderer Meinung bin, sondern eben weil mir spontan keine einfällt.

Alle, wo es angebracht ist, zwei getrennte Dokumente nebeneinader (übereinander) im Browser ansehen zu können.

Alles, was mir so in den Sinn kommt, lässt sich entweder mit einem iframe lösen (wenn die Dokumente keine gleichberechtigte Rolle erfüllen) oder kommt ganz ohne Frames und ihre Nachteile doch besser daher.

Im Grunde muss man da schon in die Richtung argumentieren, in die @Felix Riesterer gegangen ist - der Ansatz mit "offline" heißt ja im Prinzip nichts anderes als dass man keinen Server zur Verfügung hat, um mit PHP oder ähnlichem tätig zu werden, um ein Dokument zusammenzubauen, so dass ein Frameset da eine unaufwändige Alternative ist, aber auch da bleiben eben die Nachteile wie die Sache mit den Bookmarks. Also irgendwie zweifelhaft, imho.

Grüße,

RIDER

[beatovich]

hallo

... weil man ja nicht weiß/wissen will, was der Browser genau tut

Also ich will schon wissen, dass der effektive Browser meine Vorstellung versteht. eine zu idealistische Herangehensweise ist selten zielführend.

[Camping_RIDER]

Aloha ;)

... weil man ja nicht weiß/wissen will, was der Browser genau tut

Also ich will schon wissen, dass der effektive Browser meine Vorstellung versteht. eine zu idealistische Herangehensweise ist selten zielführend.

Richtig 😉 Wenn man allerdings tatsächlich nicht weiß, was der Browser im Detail tut und sich damit auch nicht tiefergehend befassen möchte, stellt das eine nicht zu vernachlässigende Vereinfachung dar, deren Logik durchaus funktioniert 😂

Wissen, dass der effektive Browser die Vorstellung versteht ≠ Wissen, was der Browser genau tut.

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben, weil man weiß, dass der Browser^[1] mindestens aufgrund Rückwärtskompatibilität solche versteht, egal wie und warum.

Ob der konkrete Browser jetzt dafür den HTML5-Parser benutzt oder Darstellungsmodi umschaltet oder einen anderen Parser benutzt oder nach Hause telefoniert oder die Berechnungen auf den Mars outsourcet ist für diesen Fakt irrelevant.

Grüße,

RIDER

---

1. Vorausgesetzt der Browser ist nicht älter als Baujahr 2000, aber davon wollen wir mal nicht ausgehen. ↩︎

[Gunnar Bittersmann]

@@Camping_RIDER

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben

Aus Gründen von UX und Barrierefreiheit reicht das nicht.

Man schreibt HTML5-Dokumente.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@Camping_RIDER

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben

Aus Gründen von UX und Barrierefreiheit reicht das nicht.

Aus Gründen der Bedienbarkeit - ganz allgemein. immer. Für jeden. Wenn es mal etwas ohne Alternative gibt, dann das.

Man schreibt HTML5-Dokumente.

So ist das!

Marc

[Camping_RIDER]

Aloha ;)

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben

Aus Gründen von UX und Barrierefreiheit reicht das nicht.

Was genau ist an „für ersteres“ (in Bezug auf „Wissen, dass der effektive Browser die Vorstellung versteht“) unverständlich?

Ich habe nie behauptet, dass das für UX und Barrierefreiheit reichen würde und ich verstehe nicht, warum du das hier aus der Luft greifst.

Ist es möglich, eine Diskussion mal in ihrem Kontext zu belassen? Ich habe keine große Lust, in jedem Posting aufs neue zu betonen, worüber wir gerade eigentlich sprechen. Ich vertraue auf das Vermögen des Lesers, die vorhergehenden Postings zu lesen und zu verstehen.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben

Aus Gründen von UX und Barrierefreiheit reicht das nicht.

Was genau ist an „für ersteres“ (in Bezug auf „Wissen, dass der effektive Browser die Vorstellung versteht“) unverständlich?

HTML 4 ist irrelevant. Du hättest „valide HTML5-Dokumente“ schreiben sollen.

Ich habe nie behauptet, dass das für UX und Barrierefreiheit reichen würde und ich verstehe nicht, warum du das hier aus der Luft greifst.

Ist es möglich, eine Diskussion mal in ihrem Kontext zu belassen? Ich habe keine große Lust, in jedem Posting aufs neue zu betonen, worüber wir gerade eigentlich sprechen.

Wenn wir über HTML und Browser sprechen, ist der übergeordnete Kontext wohl, für Nutzer benutzbare Webseiten zu erstellen.

Wenn du dann mit HTML 4 ankommst, bist du derjenige, der den Kontext verlassen hat.

LLAP 🖖

[Tabellenkalk]

Hallo,

Wenn wir über HTML und Browser sprechen, ist der übergeordnete Kontext wohl, für Nutzer benutzbare Webseiten zu erstellen.

Wieso müssen denn immer alle Webseiten benutzbar sein, kannst du nicht auch mal ein paar als Kunst durchgehen lassen? 😉

Gruß
Kalk

PS: Wetten, dass in irgendeinem Folgeposting "Kunst kommt von können" drinsteht…?

[Gunnar Bittersmann]

@@Tabellenkalk

PS: Wetten, dass in irgendeinem Folgeposting "Kunst kommt von können" drinsteht…?

Was für ein Folgeposting? Ich antworte doch nicht auf rhetorische Fragen!

Oder hab ich das jetzt etwa getan‽ Ich beherrsche die Kunst antworten zu können ohne zu antworten. Kunst kommt eben von können.

LLAP 🖖

[Tabellenkalk]

Hallo,

Kunst kommt eben von können.

Musst du mir jetzt einen ausgeben, weil ich die Wette gewonnen hab, oder ich dir weil du so ein Künstler bist?

Gruß
Kalk

[JürgenB]

Hallo,

Musst du mir jetzt einen ausgeben, weil ich die Wette gewonnen hab, oder ich dir weil du so ein Künstler bist?

ihr könnt euch ja gegenseitig einen ausgeben, bis ihr euch einig seit 🍻

Gruß
Jürgen

[beatovich]

hallo

Wenn der Preis stimmt, produziere ich auch Kunst ggg

[Camping_RIDER]

Aloha ;)

Für ersteres reicht es, valide HTML4-Dokumente zu schreiben

Aus Gründen von UX und Barrierefreiheit reicht das nicht.

Was genau ist an „für ersteres“ (in Bezug auf „Wissen, dass der effektive Browser die Vorstellung versteht“) unverständlich?

HTML 4 ist irrelevant. Du hättest „valide HTML5-Dokumente“ schreiben sollen.

Es ging hier von Anfang an um framesets, die mit HTML5 valide gar nicht möglich sind. Aber vielleicht spare ich es mir einfach.

Grüße,

RIDER

[beatovich]

hallo

Nö, Framesets hast du zuerst in die Runde geschmissen. Aber davon war am Anfang gar nie die Rede.

[Gunnar Bittersmann]

@@Camping_RIDER

Es ging hier von Anfang an um framesets, die mit HTML5 valide gar nicht möglich sind.

Ach in dem Frame stecktest du noch fest. (No pun intended.)

Ich dachte, da wären wir schon lange ausgebrochen und sprechen allgemein über HTML-Dokumente.

LLAP 🖖

[marctrix]

Hej Camping_RIDER,

Ob der konkrete Browser jetzt dafür den HTML5-Parser benutzt oder Darstellungsmodi umschaltet oder einen anderen Parser benutzt oder nach Hause telefoniert oder die Berechnungen auf den Mars outsourcet ist für diesen Fakt irrelevant.

Mag sein - dennoch ist es okay, das zu wissen - und es ist IMHO ok, wenn Gunnar sagt, wie genau etwas abläuft.

Es schadet doch niemandem, das zu wissen?!?

Marc

[MrMurphy1]

Hallo

Extern hat man alle Freiheiten intern geht überhaupt nichts.

Auch 'ne Logik. Eigenes CSS ist böse, fremdes bringt nur Gutes. Wobei CSS von Herzen aus nur gut sein kann.

Du könntest Inline-CSS verwenden, das kann nicht gesperrt werden.

Gruss

MrMurphy

[MudGuard]

Hi,

Du könntest Inline-CSS verwenden, das kann nicht gesperrt werden.

Wieso sollte der Webserver die styleattribute nicht rausfiltern können?

cu,
Andreas a/k/a MudGuard

[marctrix]

Hej MrMurphy1,

Hallo

Extern hat man alle Freiheiten intern geht überhaupt nichts.

Auch 'ne Logik. Eigenes CSS ist böse, fremdes bringt nur Gutes. Wobei CSS von Herzen aus nur gut sein kann.

Du könntest Inline-CSS verwenden, das kann nicht gesperrt werden.

Kann - muss dann vor der Auslieferung gepasst werden - ist einerseits zwar unwahrscheinlich, andererseits ist auch die Aufgabenstellung unwahrscheinlich. So was kann man sich ja in seinen kühnsten Träumen nicht ausdenken…

Marc

[Regina Schaukrug]

Du könntest Inline-CSS verwenden, das kann nicht gesperrt werden.

Kann es wohl:

Content-Security-Policy

[marctrix]

Hej Regina,

Du könntest Inline-CSS verwenden, das kann nicht gesperrt werden.

Kann es wohl:

Content-Security-Policy

Ja, genau. Das sage ich doch!

Marc

[beatovich]

hallo Ich fühle mich an Zeiten mit frames und iframes erinnert.

[Auge]

Hallo

Ich fühle mich an Zeiten mit frames und iframes erinnert.

Die habe ich als Werkzeug für Webseiten konsequent aus meinem Gedächtnis verbannt, und das, obwohl ich ihnen z.B. bei phpMyAdmin auch heute noch regelmäßig begegne. Ja, etwas zu verdrängen schützt unseren Geist.

Die Seiten sehen ohne CSS natürlich auch mit Frames nackelig aus. Da beißt die Maus keinen Faden ab. :-)

Tschö, Auge

[beatovich]

iframes haben für mich immer noch eine Berechtigung als NoScript Fallback Variante. Und NoScript ist in meiner Welt erst mal der Standard.

[Mitleser]

Ich fühle mich an Zeiten mit frames und iframes erinnert. Die habe ich als Werkzeug für Webseiten konsequent aus meinem Gedächtnis verbannt,

iFrames haben durchaus noch Ihre Daseinsberechtigung, z.B. für Widgets, die man in Ihrem Kontext fahren und anbieten möchte.

und das, obwohl ich ihnen z.B. bei phpMyAdmin auch heute noch regelmäßig begegne.

Das werden dann aber schon recht betagte Versionen sein. Im Default läuft der phpMyAdmin schon geraume Zeit ohne Frames.

[Auge]

Hallo

Ich fühle mich an Zeiten mit frames und iframes erinnert. Die habe ich als Werkzeug für Webseiten konsequent aus meinem Gedächtnis verbannt,

iFrames haben durchaus noch Ihre Daseinsberechtigung, z.B. für Widgets, die man in Ihrem Kontext fahren und anbieten möchte.

Ihre Daseinsberechtigung habe ich ihnen mit keinem Wort abgesprochen. Ich nutze sie aber nicht. Demnach können sie aus meinem Gedächtnis auch raus.

und das, obwohl ich ihnen z.B. bei phpMyAdmin auch heute noch regelmäßig begegne.

Das werden dann aber schon recht betagte Versionen sein. Im Default läuft der phpMyAdmin schon geraume Zeit ohne Frames.

Da hast du recht. Da die Seitenaufteilung immer noch so aussieht, als würden Frames benutzt, habe ich mich zu dieser Fehlannahme hinreißen lassen.

Tschö, Auge

[Camping_RIDER]

Aloha ;)

Wie kann ich mit reinem HTML eine halbwegs ansprechende Menü-Bar erstellen. Diese soll Elemente (Bilder) enthalten und jeweils Text im Body der Seite laden bei klick. Ich dachte da an einfache Links, weiß ich nicht wie ich ohne CSS oder JS den Content entsprechend anpassen kann.

Das hört sich für mich so an als würdest du versuchen, ein Frameset nachzubauen. Schlechte Idee. Framesets waren schon immer schlecht für den Nutzer und sind seit HTML5 auch offiziell raus aus der Herde.

Ansonsten kann ich mich nur den Ausführungen von Auge anschließen.

Grüße,

RIDER

[Jens Funkenberger]

Hallo Rider,

Ja, damit hast Du natürlich absolut Recht. Aber ich bin etwas verzweifelt und würde alles versuchen um den Content irgendwie brauchbar zu gestalten.

[marctrix]

Hej Jens,

Ja, damit hast Du natürlich absolut Recht. Aber ich bin etwas verzweifelt und würde alles versuchen um den Content irgendwie brauchbar zu gestalten.

Es gehen Dinge, die aus gutem Grund von jedem ernsthaften Entwickler abgelehnt werden. Man kann diverse Elemente missbrauchen, um die Darstellung zu beeinflussen. Das sind aber üble Hacks. Wenn <style></style> nicht geht, geht denn <div style="">?

Marc

[Gunnar Bittersmann]

@@marctrix

Es gehen Dinge, die aus gutem Grund von jedem ernsthaften Entwickler abgelehnt werden. Man kann diverse Elemente missbrauchen, um die Darstellung zu beeinflussen. Das sind aber üble Hacks.

Und wenn man sich schon solcher bedient, nicht vergessen, die Rolle des missbrauchten Elements wieder richtig zu rücken: bspw. <h4 role="presentation">

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

nicht vergessen, die Rolle des missbrauchten Elements wieder richtig zu rücken: bspw. <h4 role="presentation">

<h4 role="none">

• Jan Hellbusch: Es gibt immer noch zu viele Layout-Tabellen im Web. role="none" hilft
  • http://www.barrierefreies-webdesign.de/knowhow/layout-tabellen/
• Matthias Apsel: Was spricht gegen role="presentation"?
• Jan Hellbusch: "none" (ARIA 1.1) und "presentation" (ARIA 1.0/1.1) sind identisch, aber "presentation" wird irgendwann deprecated.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

• Jan Hellbusch: "none" (ARIA 1.1) und "presentation" (ARIA 1.0/1.1) sind identisch, aber "presentation" wird irgendwann deprecated.

Allerdings: Until implementations include sufficient support for role="none", web authors are advised to use the presentation role alone role="presentation" or redundantly as a fallback to the none role role="none presentation". (wai-aria 1.1)

Bis demnächst
Matthias

[beatovich]

hallo

Deine Aufgabe erinnert mich an einen Test. Der Test könnte lauten: Wenn du semantisch korretes und sinnvolles HTML schreibst, wird ein suspendiertes CSS sofort sinnvolle Resultate erzeugen.

Ich würde an deiner Stelle ganz einfach noch mal nachfragen.