Kommunikation, HTML, usw.

[TS]

Hello @all,

bei dieser Gelegenheit mal Eure Meinung erfragt:

Wie lange wird es HTML und Co. noch geben?

Wenn man heute die Forderung stellt, dass SchüleX durchaus Grundlagen von HTML und der Webtechniken lernen sollen, und dies am besten in einem eigenen Unterrichtshauptfach "technische Kommunikation", wird das dann in zehn Jahren im Rückblick lächerlich sein?

Glück Auf
Tom vom Berg

[Auge]

Hallo

Wie lange wird es HTML und Co. noch geben?

In einer Welt, in der für immer mehr Aufgaben auf Webapps statt OS-basierter Programme gesetzt wird, wohl für einen überschaubar langen Zeitraum. Ich habe jedenfalls noch nicht von einer neuen Technik künden hören, die die Kombi HTML-CSS-JS ablösen könnte.

Tschö, Auge

[dedlfix]

Tach!

Ich habe jedenfalls noch nicht von einer neuen Technik künden hören, die die Kombi HTML-CSS-JS ablösen könnte.

WebAssembly ist zumindest in der Lage, Javascript einen großen Teil des Rangs abzulaufen. Nicht vollständig, denn man hat das nicht komplett neu in die Browser eingebettet, sondern man nutzt die Javascript-APIs, um darüber von WebAssembly-Code aus die Browsergegebenheiten (DOM etc.) anzusprechen.

Ansonsten wird wohl auch erst jemand mit einer ähnlich bahnbrechenden Erfindung um die Ecke kommen müssen, wie es HTML damals war.

dedlfix.

[TS]

Hello Dedlfix,

Ansonsten wird wohl auch erst jemand mit einer ähnlich bahnbrechenden Erfindung um die Ecke kommen müssen, wie es HTML damals war.

Da muss man vermutlich gar nichts neues erfinden müssen, sondern die Spirale der Entwicklung nur um eine Umdrehumg weiterdrehen.

HTML betrachte ich als Weiterentwicklung von ANSI-Sequenen u. ä..
HTML hat einen gravierenden Nachteil. Es müssen für jedes Update des Dokumentes sowohl das Markup, als auch die neuen Daten übertragen werden. Durch Hilfstechniken, wie AJAX % Co. kann man das verhindern. Durch schnellere Leitungen kann man Medizin aufs Problem schütten.

Man könnte aber auch den HTML-Standard weiterentwickeln, sodass bei einem Datenupdate das Markup nicht erneut übertragen werden muss. Sollten doch Änderungen notwendig sei, werden eben nur diese übermittelt.

Aber vermutlich wäre es trotzdem keine überflüssige Mühe, wenn SchülerX heute schon die Basis des evtl. Zukünftigen kennen lernen.

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Ansonsten wird wohl auch erst jemand mit einer ähnlich bahnbrechenden Erfindung um die Ecke kommen müssen, wie es HTML damals war.

Man könnte aber auch den HTML-Standard weiterentwickeln, sodass bei einem Datenupdate das Markup nicht erneut übertragen werden muss. Sollten doch Änderungen notwendig sei, werden eben nur diese übermittelt.

Ich glaube nicht, dass das bahnbrechend genug ist, um einen ganz neuen Ansatz zu fahren.

Ich denke, wenn es eine Technologie gibt, die HTML irgendwann mal ablöst, dann muss es eine Technologie sein, die ganz wesentliche Dinge erreicht, die mit HTML gar nicht möglich sind – denn bei kleineren Dingen wie zum Beispiel dem, was du nanntest, wo man den Effekt schon heute ohne Schwierigkeit mit JS/AJAX erreichen kann, ist vermutlich schlicht die Schwelle für eine neue Technologie im Vergleich zur tatsächlich erreichten Optimierung zu groß.

Aber vermutlich wäre es trotzdem keine überflüssige Mühe, wenn SchülerX heute schon die Basis des evtl. Zukünftigen kennen lernen.

Ich verstehe nicht ganz, was du sagen willst. Was sollen die Schüler schon heute lernen? HTML? Oder das was eventuell in Zukunft an Neuem kommt? Falls letzteres: Wie soll das sinnvoll umsetzbar sein?

Grüße,

RIDER

[TS]

Hello Rider,

Man könnte aber auch den HTML-Standard weiterentwickeln, sodass bei einem Datenupdate das Markup nicht erneut übertragen werden muss. Sollten doch Änderungen notwendig sei, werden eben nur diese übermittelt.

Ich glaube nicht, dass das bahnbrechend genug ist, um einen ganz neuen Ansatz zu fahren.

Das denke ich auch nicht. Es wäre maximal eine Vierteldrehung...

Der bahnbrechende Schritt von ANSI-Sequenzen zu HTML war das Hyper, also HTTP und Client-Multiserver.

Der entscheidende Kick fehlt da noch. Aber dieser wird dann wieder alle "Prokeleien", wie AJAX, Websockets, vielleicht auch CSS, usw. zusammenfassen zu einer neuen, leichter verständlichen Technik. Man wird dann (wieder) auf einen Blick die Zusammenhänge erkennen können.

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Der entscheidende Kick fehlt da noch. Aber dieser wird dann wieder alle "Prokeleien", wie AJAX, Websockets, vielleicht auch CSS, usw. zusammenfassen zu einer neuen, leichter verständlichen Technik. Man wird dann (wieder) auf einen Blick die Zusammenhänge erkennen können.

Wobei gerade im Verhältnis HTML / CSS separation of concerns ja allgemein eher als Vorteil gesehen wird.

Nun ja. Du hast Recht - man darf gespannt sein, was da kommt. Falls etwas kommt. Sicher bin ich mir da nicht.

Grüße,

RIDER

[TS]

Hello,

Der entscheidende Kick fehlt da noch. Aber dieser wird dann wieder alle "Prokeleien", wie AJAX, Websockets, vielleicht auch CSS, usw. zusammenfassen zu einer neuen, leichter verständlichen Technik. Man wird dann (wieder) auf einen Blick die Zusammenhänge erkennen können.

Wobei gerade im Verhältnis HTML / CSS separation of concerns ja allgemein eher als Vorteil gesehen wird.

Nun ja. Du hast Recht - man darf gespannt sein, was da kommt. Falls etwas kommt. Sicher bin ich mir da nicht.

Vielleicht ist es auch die mMn noch fehlende Konsequenz innerhalb und zwischen den heutigen Techniken, die zur zeitweisen Unübersichtlichkeit beiträgt.

Da hat mMn HTML5 schon eine Menge bereinigt. Aber das ist eben nur innerhalb einer Komponente des Gesamtkunstwerks.

Glück Auf
Tom vom Berg

[1unitedpower]

Nun ja. Du hast Recht - man darf gespannt sein, was da kommt. Falls etwas kommt. Sicher bin ich mir da nicht.

Ich glaube auch nicht an einen harten Umbruch. Das Mantra "Don't break the web" wird auch in der vorhersehbaren Zukunft seine Grundsätzlichkeit behaupten und invasive Eingriffe in das existierende Web unterbinden. Eine Revolution an deren Ende wieder ein monopolistischer Programmierstack steht, der die heutigen Monopolisten HTML/CSS/JS ablöst, ist nur schwer vorstellbar. Aber vieles spricht dafür, dass zur Zeit eine technische Liberalisierung des Webs stattfindet und zwar auf eine mit dem Web verträglichen evolutionären Weise.

Ein paar Beispiele: Die interne Skripting Schnittstelle der Browser war bisher ein exklusiver Raum für JavaScript. Heute gibt es WebAssembly, das vereinfacht den Markteintritt anderer Programmiersprachen ins Web. Es gibt bereits jetzt eine Fülle an Programmiersprachen, die zu JavaScript oder zu WebAssembly kompiliert werden können, das werden in Zukunft noch mehr werden und auch der Arbeitsmarkt wird sich indessen Folge verändern.

Ähnlich sieht es bei CSS aus. Wir haben seit ein paar Jahren WebGL, eine low-level Schnittstelle für visuelle Darstellungen und mitunter ein Baustein, um alternative User Interfaces zu entwickeln. Der hauptsächliche Anwendungsbereich konzentriert sich momentan auf Computer-Spiele, aber mich würde es nicht überraschen, wenn WebGL seinen Anwendungsbreich in Zukunft weiter ausdehnen können wird.

Außerdem treibt das W3C unter dem Schirmbegriff "CSS Houdini" Bemühungen voran CSS auf einer tiefer liegenden Ebene zu standadisieren und die Rendering Pipelines der Browser für Scripting zu öffnen. Die Bemühungen sind heute noch eher experimenteller Natur, aber offensichtlich besteht da ein Bedarf und ein Wille etwas in dieser Hinsicht zu unternehmen.

HTML wird gerade ebenfalls weiter geöffnet, das Shadow DOM und Custom-Elements sind zwei Beispiele dafür.

Und, um ein letztes Beispiel zu nennen, wir beobachten ständig das Enstehen neuer Web APIs, die Aufgaben ermöglichen, die bisher nur von nativen Programmen erfüllt werden konnten.

Das weckt in mir den Optimismus, dass das technische Ökosystem, das das Web antreibt, in Zukunft noch vielfältiger und innovativer werden wird. Sorgen macht mir, dass damit die Anforderungen an Browser enorm wachsen und der Markteintritt für neue Browser immer schwieriger werden wird. Selbst Microsoft musste sich dieser Entwicklung jünsgt geschlagen geben und hat verkündet, dass ihr nächster Browser auf Chromium aufbauen wird.

[Camping_RIDER]

Aloha ;)

Sorgen macht mir, dass damit die Anforderungen an Browser enorm wachsen und der Markteintritt für neue Browser immer schwieriger werden wird. Selbst Microsoft musste sich dieser Entwicklung jünsgt geschlagen geben und hat verkündet, dass ihr nächster Browser auf Chromium aufbauen wird.

Du hast da völlig Recht, trotzdem will ich das ein wenig abmildern, denn zum Glück sind im Bereich der Browser die wesentlichen Browser/Rendering Engines immerhin F(L)OSS, was andersherum gesehen auch späteren Markteintretern die Möglichkeit gibt, darauf aufzubauen und nicht von vorne anfangen zu müssen.

Will sagen: Ich habe deutlich weniger Probleme mit geringer Diversität in einem Softwarebereich, wenn ein nennenswerter Marktanteil durch F(L)OSS-Software abgedeckt wird, da die Gefahren eines tatsächlichen Monopols aus meiner Warte geringer erscheinen.

Um ein Beispiel zu geben: Mit der Dominanz von Microsoft Office im Office-Bereich habe ich ein deutlich größeres Problem als mit der Dominanz von Browsern, die auf Chromium^[1] basieren, im Web, zumal Chromium ja auch F(L)OSS-Mitbewerber hat, LibreOffice hingegen nicht wirklich.

Grüße,

RIDER

---

1. Um potenzielle Missverständnisse auszuschließen: Die Dominanz von Google Chrome sehe ich natürlich auch als Problem, dadurch wird Chromium aber nicht problematischer. ↩︎

[Der Martin]

Hallo,

HTML betrachte ich als Weiterentwicklung von ANSI-Sequenen u. ä..

also ich nicht: Die alten ANSI-Terminalsteuerzeichen hatten ja nur visuelle Funktion: Farben umschalten, Cursor positionieren, irgendwas in der Art. Also ansatzweise eher das, was CSS heute leistet.
Ein Bruchteil davon.

HTML dagegen vermittelt Inhalt und Struktur der Information. Das leisten die Steuerzeichen oder Escape-Sequenzen im Text nicht.

HTML hat einen gravierenden Nachteil. Es müssen für jedes Update des Dokumentes sowohl das Markup, als auch die neuen Daten übertragen werden.

Ja und? Das sind bei mäßig komplexen Dokumenten mal 10..20kB, meinetwegen 50k. Und nur ein Bruchteil davon entfällt aufs Markup. Das fällt also nicht ins Gewicht.

Man könnte aber auch den HTML-Standard weiterentwickeln, sodass bei einem Datenupdate das Markup nicht erneut übertragen werden muss.

Du willst unformatierten Rohtext übertragen und der Browser soll den wieder ins Dokument pfropfen, während du mit, sagen wir, 5% mehr Datenvolument wieder ein komplettes Dokument hättest?

So long,
 Martin

[TS]

Hello,

HTML betrachte ich als Weiterentwicklung von ANSI-Sequenen u. ä..

also ich nicht: Die alten ANSI-Terminalsteuerzeichen hatten ja nur visuelle Funktion: Farben umschalten, Cursor positionieren, irgendwas in der Art. Also ansatzweise eher das, was CSS heute leistet.

Darum nenne ich es ja auch Weiterentwicklung. Die Semantikinformation ist hinzugekommen, während die absolute Positionsinformation zunächst weggefallen ist, aber mit CSS wieder aufgetaucht ist.

HTML hat einen gravierenden Nachteil. Es müssen für jedes Update des Dokumentes sowohl das Markup, als auch die neuen Daten übertragen werden.

Ja und? Das sind bei mäßig komplexen Dokumenten mal 10..20kB, meinetwegen 50k. Und nur ein Bruchteil davon entfällt aufs Markup. Das fällt also nicht ins Gewicht.

Dann siehst Du nur die statischen Anwendungsfälle. Ich sehe aber auch solche, bei denen Charts nebst Beschreibungen dynamisch aktualisiert werden sollen u. ä. (durch Serverpush). Und iche sehe bestimmt nicht alle Möglichkeiten.

Da hat man selbstverständlich zur Zeit schon Lösungen, die sind aber nicht sehr sevicefreundlich und unübersichtlich.

Man könnte aber auch den HTML-Standard weiterentwickeln, sodass bei einem Datenupdate das Markup nicht erneut übertragen werden muss.

Du willst unformatierten Rohtext übertragen und der Browser soll den wieder ins Dokument pfropfen, während du mit, sagen wir, 5% mehr Datenvolument wieder ein komplettes Dokument hättest?

Da hast Du jetzt aber bei der Prozentrechnung geschummelt. Um zyklisch aber unregelmäßig einen Balken in einer Balkengrafik zu ändern oder einige Punkte in einer SVG-Grafik zu ergänzen muss man nicht ständig das ganze Dokument übertragen. Es würde reichen, einen Header sowie die Datenpaare ID - Wert hinterherzuschieben. Wenn jedes betroffene Element eine ID hätte, wüsste der entsprechend gebaute Browser sofort, wohin er die Daten schieben müsste und wie sie im entsprechenden Element darzustellen sind. Das wurde ja beim Übertragen des Startdokumentes vereinbart.

.

Brainstorming

Versuch doch mal, ähnliche Entwicklungswünsche zu erfinden und nicht gegenzureden. Ist doch nur Brainstorming. Wenn ich die diffusen Gedanken hierzu schon klar formulieren könnte, müsste ich die Entwicklung (der Gedanken) nur noch durchführen und aufsvhreiben und ein neuer Standardentwurf wäre gebohren.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Dann siehst Du nur die statischen Anwendungsfälle. Ich sehe aber auch solche, bei denen Charts nebst Beschreibungen dynamisch aktualisiert werden sollen u. ä. (durch Serverpush). Und iche sehe bestimmt nicht alle Möglichkeiten.

Da hat man selbstverständlich zur Zeit schon Lösungen, die sind aber nicht sehr sevicefreundlich und unübersichtlich.

Hast du mal komponentenbasiert gearbeitet? Wenn die Daten einer Komponenten geändert werden sollen, besorgt ein Service die neuen Daten und die Komponente aktualisiert sich. Finde ich servicefreundlich und übersichtlich.

Ist allerdings Javascript-basiert und die Suchmaschinen tun sich schwer damit. Für Anwendungen, die nicht durchsucht werden müssen, ist das kein Problem. Aber ich meine auch bei dir zu erkennen, dass da Datenverarbeitung der vorwiegende Anwendungsfall ist und weniger Informationspräsentation.

dedlfix.

[Der Martin]

Tuten Gag,

HTML betrachte ich als Weiterentwicklung von ANSI-Sequenen u. ä..

also ich nicht: Die alten ANSI-Terminalsteuerzeichen hatten ja nur visuelle Funktion: Farben umschalten, Cursor positionieren, irgendwas in der Art. Also ansatzweise eher das, was CSS heute leistet.

Darum nenne ich es ja auch Weiterentwicklung. Die Semantikinformation ist hinzugekommen, während die absolute Positionsinformation zunächst weggefallen ist, aber mit CSS wieder aufgetaucht ist.

gut, dann hast du den Begriff Weiterentwicklung aber IMO sehr stark strapaziert.

Ja und? Das sind bei mäßig komplexen Dokumenten mal 10..20kB, meinetwegen 50k. Und nur ein Bruchteil davon entfällt aufs Markup. Das fällt also nicht ins Gewicht.

Dann siehst Du nur die statischen Anwendungsfälle. Ich sehe aber auch solche, bei denen Charts nebst Beschreibungen dynamisch aktualisiert werden sollen u. ä. (durch Serverpush).

Das ist dann aber etwas völlig anderes als ich aus deinem Beitrag ursprünglich herausgelesen habe. "Nur einzelne Elemente" oder "nur ein Teilbereich" ist etwas anderes als "nur den Inhalt, aber nicht das Markup" neu übertragen. Da hatte ich herausgelesen, dass du den gesamten Textinhalt auffrischen wolltest.

Du willst unformatierten Rohtext übertragen und der Browser soll den wieder ins Dokument pfropfen, während du mit, sagen wir, 5% mehr Datenvolument wieder ein komplettes Dokument hättest?

Da hast Du jetzt aber bei der Prozentrechnung geschummelt.

Ja, kann sein, dass der Markup-Anteil noch geringer ist.

Um zyklisch aber unregelmäßig einen Balken in einer Balkengrafik zu ändern oder einige Punkte in einer SVG-Grafik zu ergänzen muss man nicht ständig das ganze Dokument übertragen. Es würde reichen, einen Header sowie die Datenpaare ID - Wert hinterherzuschieben. Wenn jedes betroffene Element eine ID hätte, wüsste der entsprechend gebaute Browser sofort, wohin er die Daten schieben müsste und wie sie im entsprechenden Element darzustellen sind. Das wurde ja beim Übertragen des Startdokumentes vereinbart.

Ja, d'accord. Aber den Gedanken konnte ich aus deinem vorherigen Beitrag nicht herauskristallisieren.

Versuch doch mal, ähnliche Entwicklungswünsche zu erfinden und nicht gegenzureden.

Das ist gegen meine Natur. ;-)

Ich bin von Haus aus sehr konservativ im eigentlichen Sinn des Wortes. Will heißen, ich versuche nach Möglichkeit, den Status Quo zu erhalten. Ich bin durchaus bereit, Neues zu akzeptieren, wenn ich den Vorteil erkenne. Aber ich lege es nicht selbst darauf an, wenn ich mit der Gegenwart zufrieden bin.

Schönes Wochenende,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Ich bin von Haus aus sehr konservativ im eigentlichen Sinn des Wortes. Will heißen, ich versuche nach Möglichkeit, den Status Quo zu erhalten.

Die Grundfunktionalität für alle.

Ich bin durchaus bereit, Neues zu akzeptieren, wenn ich den Vorteil erkenne. Aber ich lege es nicht selbst darauf an, wenn ich mit der Gegenwart zufrieden bin.

Wenn du daraus „den Vorteil für manche“ machst (das können viele sein oder auch wenige; du selbst musst nicht einmal eingeschlossen sein), bis du bei progressive enhancement. \o/

LLAP 🖖

[Der Martin]

Mahlzeit,

Wie lange wird es HTML und Co. noch geben?

wenn ich bedenke, dass es HTML schon "ewig" gibt, und CSS auch schon sehr lange, und dann noch überlege, dass es zumindest im Web derzeit auch keine Alternativen gibt ... vermutlich noch sehr lange.

Wenn man heute die Forderung stellt, dass SchüleX durchaus Grundlagen von HTML und der Webtechniken lernen sollen, und dies am besten in einem eigenen Unterrichtshauptfach "technische Kommunikation", wird das dann in zehn Jahren im Rückblick lächerlich sein?

Das glaube ich nicht.

Passend zum Topic: Ich habe in der Firma vor ein paar Tagen eine Kurz-Präsentation gehalten. Da ich der Meinung bin, dass Powerpoint total überbewertet wird (und auch nicht wirklich komfortabel zu bedienen), habe ich die Präsentation mit HTML/CSS aufgebaut und im Browser im Full-Screen-Modepräsentiert.

Ich bin überzeugt, ein paar Kollegen haben den Unterschied gar nicht bemerkt; ein paar aus der R&D kamen aber hinterher auf mich zu und haben sich neugierig erkundigt, wie/womit ich das gemacht hätte.
"Cool", fanden zwei von ihnen, "das machen wir nächstes Mal auch so."

Ciao,
 Martin

[Matthias Scharwies]

Servus!

Passend zum Topic: ... habe ich die Präsentation mit HTML/CSS aufgebaut und im Browser im Full-Screen-Modepräsentiert.

Ich bin überzeugt, ein paar Kollegen haben den Unterschied gar nicht bemerkt; ein paar aus der R&D kamen aber hinterher auf mich zu und haben sich neugierig erkundigt, wie/womit ich das gemacht hätte.
"Cool", fanden zwei von ihnen, "das machen wir nächstes Mal auch so."

Ich hatte mal etwas mit CSSS von Lea Verou rumprobiert. Wie hast du das aufgebaut?

Hättest du Lust einen Blog-Beitrag dazu zu schreiben?

Herzliche Grüße

Matthias Scharwies

[Der Martin]

Hallo,

Passend zum Topic: ... habe ich die Präsentation mit HTML/CSS aufgebaut und im Browser im Full-Screen-Modepräsentiert.

Ich hatte mal etwas mit CSSS von Lea Verou rumprobiert. Wie hast du das aufgebaut?

mit der Hand am Arm. "From scratch".

Jede Seite in einem eigenen Containerelement, alle zunächst display:none, dann eins von ihnen mit :target wieder sichtbar gemacht. Noch ein Javascript-keydown-Handler, um auch bequem per Tastatur navigieren zu können: Cursor links/rechts für eine Seite vor/zurück, und Zifferntasten zum direkten Anspringen einer Seite.

Gemacht für Firefox, tut aber ebensogut im Zwillingsbruder Pale Moon, IE11 (IE12 nicht getestet), ein Kollege hat's im aktuellen Chrome probiert, auch okay.

Hättest du Lust einen Blog-Beitrag dazu zu schreiben?

Das wäre dann schon der zweite auf der Liste "Jemand möchte, dass ich ..."
Aber das ist schon okay, ich mach's ja gern. Kann nur nicht sicher sagen, wann.

Schönes Wochenende,
 Martin

[Mitleser]

Gemacht für Firefox, tut aber ebensogut im Zwillingsbruder Pale Moon, IE11 (IE12 nicht getestet), ein Kollege hat's im aktuellen Chrome probiert, auch okay.

IE12? Habe ich was verpasst? 😲

[Matthias Scharwies]

Servus!

Gemacht für Firefox, tut aber ebensogut im Zwillingsbruder Pale Moon, IE11 (IE12 nicht getestet),

IE12? Habe ich was verpasst? 😲

Irgendwann kommt jetzt Edge 76 mit der Rendering Engine von Chrome. Da kann man endlich den IE11 von allen Maschinen schmeißen.

Computer-Bild: Edge Chromium: Testversionen für Windows 7, 8 und 8.1 verfügbar!

Herzliche Grüße

Matthias Scharwies

[Mitleser]

Irgendwann kommt jetzt Edge 76 mit der Rendering Engine von Chrome.

Ja, soweit klar. Nur davon unabhängig ist mir IE12 bislang nie vor die Füsse gefallen. IE 11. Danach Edge. Fertig.

Da kann man endlich den IE11 von allen Maschinen schmeißen.

Was hat das denn damit zu tun?

Internet Explorer 11 will be supported for the life of Windows 7, Windows 8.1, and Windows 10

[Auge]

Hallo

Irgendwann kommt jetzt Edge 76 mit der Rendering Engine von Chrome. Da kann man endlich den IE11 von allen Maschinen schmeißen.

Erzähl mal, wie du das zu tun gedenkst. Der einzige mir bekannte Weg ist, das MS-Betriebsystem durch eines eines anderen Anbieters zu ersetzen. Das geht aber nicht erst mit dem Erscheinen des Edge 76, sondern schon seit Jahrzehnten.

Tschö, Auge

[Der Martin]

Hallo,

Gemacht für Firefox, tut aber ebensogut im Zwillingsbruder Pale Moon, IE11 (IE12 nicht getestet), ein Kollege hat's im aktuellen Chrome probiert, auch okay.

IE12? Habe ich was verpasst? 😲

IE12 a.k.a. Edge.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

IE12 a.k.a. Edge.

Ich glaube, damit tust du Edge unrecht.

LLAP 🖖

[dedlfix]

Tach!

IE12 a.k.a. Edge.

Ich glaube, damit tust du Edge unrecht.

Und auch dem IE. Der Edge hat eine Menge Dinge verloren, weswegen man den IE im Firmenumfeld einsetzte. Zum Beispiel Single Sign-on. Wer braucht das schon? Sollen sich doch die Anwender am System und pro Anwendung(sstart) einzeln anmelden.

dedlfix.

[Mitleser]

Und auch dem IE. Der Edge hat eine Menge Dinge verloren, weswegen man den IE im Firmenumfeld einsetzte. Zum Beispiel Single Sign-on. Wer braucht das schon? Sollen sich doch die Anwender am System und pro Anwendung(sstart) einzeln anmelden.

Wohl einer der Gründe, warum der IE11 noch auf unbestimmte Zeit Support bekommt.

[Gunnar Bittersmann]

@@Mitleser

Und auch dem IE. Der Edge hat eine Menge Dinge verloren, weswegen man den IE im Firmenumfeld einsetzte. Zum Beispiel Single Sign-on. Wer braucht das schon? Sollen sich doch die Anwender am System und pro Anwendung(sstart) einzeln anmelden.

Wohl einer der Gründe, warum der IE11 noch auf unbestimmte Zeit Support bekommt.

Wohl einer der Gründe, warum der IE11-Modus in den Chromium-Edge eingebaut wurde.

LLAP 🖖

[Mitleser]

Wohl einer der Gründe, warum der IE11 noch auf unbestimmte Zeit Support bekommt.

Wohl einer der Gründe, warum der IE11-Modus in den Chromium-Edge eingebaut wurde.

Wohl einer der Gründe, warum (zumindest „unter der Haube“) der IE11 weiter leben wird.

[Mitleser]

Ich hatte mal etwas mit CSSS von Lea Verou rumprobiert. Wie hast du das aufgebaut?

Ich finde https://revealjs.com/ sehr cool.

[1unitedpower]

Ich hab den Thread mal ausgelagert, weil er einen recht großen thematischen Bruch zum Ursprungsthread begeht uns auch gut für sich alleine stehen kann. Darf gerne rückgängig gemacht werden, wenn ihr das anders seht.

[Camping_RIDER]

Aloha ;)

Ich hab den Thread mal ausgelagert, weil er einen recht großen thematischen Bruch zum Ursprungsthread begeht uns auch gut für sich alleine stehen kann. Darf gerne rückgängig gemacht werden, wenn ihr das anders seht.

JETZT weiß ich, was meine Notifications zerstört hat.

Aber ja, du hast völlig Recht.

Grüße,

RIDER

[Lisa]

Hallo,

Wie lange wird es HTML und Co. noch geben?

Ich hoffe noch lange. Was sich aber ändern wird und schon getan hat ist das Verhältnis zwischen Webseitenbetreiber und HTML-Interessierten. Es wird halt immer einfacher eine Seite zu erstellen ohne den Hintergrund zu kennen. Ich vergleiche das mal mit Programmen wie Open-Office, Word, etc. Ich nutze das und bekomme auch meine Ergebnisse, warum das letztendlich so funktioniert ist mir egal. Sieht man auch, kann auch subjektives Empfinden sein, wie die Besucherzahl bei Fachforen allgemein sinkt, während baukastenthematische Foren Zulauf bekommen.

lg.

[encoder]

Wie lange es das noch geben wird - keine Ahnung.

Allerdings wäre es gut wenn es in Sachen Web nicht so laufen wird wie bei Programmiersprachen, wo es "täglich" was neues gibt und wegen einem neuen Feature gleich alles andere auch noch umgestellt wird.
Das würde nur diese idiotischen Hinweise "optimiert für Browser xy" wieder aufbringen - und die hat doch wirklich keiner gebraucht 😉