Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Dark Mode für Webseiten: Neue Safari Technology Preview erlaubt Anpassungen für Dunkel-Modus

Mit macOS Mojave führte Apple einen neuen Dunkel-Modus im Betriebssystem ein: Der gesamte Desktop, das Dock, die Menuleiste und alle Fenster kompatibler Programme passen sich automatisch an das ausgewählte Theme an. Beim Betrachten von Webseiten kann der Dunkel-Modus aber schnell nervig werden: Oftmals strahlt dem Nutzer eine hell gestaltete Internetseite entgegen und führt den Dark Mode ad absurdum. Dritthersteller können Apps mit macOS Mojave an den Dunkel-Modus anpassen, Webseiten erhalten aber derzeit von Safari nicht genügend Informationen, um sich ebenfalls in einem angeglichenen Farbschema darzustellen.


Zwar gibt es manche Safari-Plugins, welche den Versuch unternehmen, das Aussehen von Webseiten an den Dunkel-Modus anzupassen – diese funktionieren aber meist nur in wenigen Fällen zufriedenstellend.

In der gerade erschienenen Safari Technology Preview 68 nahm Apple diesbezüglich eine Anpassung vor: Für Webseitenbetreiber gibt es zukünftig über CSS (mit der Media-Query "prefers-color-scheme") die Möglichkeit, abfragen, welches Farbschema der Nutzer gewählt hat. Auf diese Weise können sich Internetseiten automatisch an das eingestellte Theme anpassen, so dass ein homogeneres Gesamtbild auf dem Desktop entsteht.

Noch ist nicht bekannt, wann Apple diese Änderung in einem macOS-Update für die reguläre Safari-Version freigibt. Da macOS 10.14.1 bereits in der fünften Entwicklervorabversion vorliegt, dürfte Apple eine solche Anpassung in dieser späten Testphase nicht mehr einpflegen. Es ist wahrscheinlicher, dass Apple die Änderung mit macOS 10.14.2 oder 10.14.3 für alle Nutzer freigibt. Webseitenbetreiber müssen aber ihre Internetseiten an die neue Funktionalität anpassen, was je nach Komplexität der Seite einiges an Aufwand bedeutet.

Kommentare

Fenvarien
Fenvarien25.10.18 09:14
Um die Frage gleich vorwegzunehmen: Wir prüfen momentan, wie wir das für MTN umsetzen können
Up the Villa!
+8
wormstar
wormstar25.10.18 09:26
Fenvarien
Um die Frage gleich vorwegzunehmen: Wir prüfen momentan, wie wir das für MTN umsetzen können

Es wäre schön, wenn Ihr von Euren Erfahrungen bei der Umsetzung berichten könntet
0
Mendel Kucharzeck
Mendel Kucharzeck25.10.18 09:36
wormstar
Klar: Bilder ohne Alpha-Maske sind ganz großer Mist!
+4
trw
trw25.10.18 09:39
Fenvarien
Um die Frage gleich vorwegzunehmen: Wir prüfen momentan, wie wir das für MTN umsetzen können

Sehr cool .... da freu ich mich schon drauf!
(momentan "spiele" bzw teste ich in Safari an Wenseiten öfter die Erweiterungen "Dark Mode" und "Darker Reader" ... macht bei manchen Seiten Spaß, bei manchen weniger! )
0
sierkb25.10.18 09:45
Außerdem mit Safari Technology Preview 68 eingeführt ist der VP8 codec (die Nachfolgecodecs VP9 und AV1 werden sicher demnächst folgen):

Apple Adds VP8 Support for WebRTC to Safari Technology Preview Release 68

Aktivierbar mit:

Safari Technology Preview Develop Experimental Features [✓] WebRTC VP8 codec

Siehe auch:

WebKit Blog (24.10.2018): Release Notes for Safari Technology Preview 68 :
WebRTC
  • Added VP8 support to WebRTC (r236821)
  • Added support for IceCandidate stats (r236963)
  • Added support for reporting “display composited video frames” through the VideoPlaybackQuality object (r236875)
  • Added support for RTCPeerConnection.generateCertificate (r237140)
  • Added support for RTCConfiguration.certificates (r237202)
  • Implemented error handler of MediaRecorder (r237106)

Apple Developer: Safari Technology Preview Release Notes: Release 68 :
WebRTC
  • Added VP8 support to WebRTC
  • Added support for IceCandidate stats
  • Added support for reporting “display composited video frames” through the VideoPlaybackQuality object
  • Added support for RTCPeerConnection.generateCertificate
  • Added support for RTCConfiguration.certificates
  • Implemented error handler of MediaRecorder


Lorenzo Miniero via Twitter, 11.10.2018
Hey, hell really did freeze and pigs started to fly! 😁 Kudos to the Safari team for finally doing the right thing, I honestly didn't expect this would ever happen
Q:
0
AJVienna25.10.18 09:59
Fenvarien
Um die Frage gleich vorwegzunehmen: Wir prüfen momentan, wie wir das für MTN umsetzen können
Mir wäre am iPhone X mit OLED auch ein schwarzes Layout lieber.
0
Paddy259025.10.18 10:18
Warum gibt es keinen vernünftigen Dark Mode für iOS? Bei den OLED Displays würde sich das doch richtig lohnen. Ja, ich weiß, es gibt Farben umkehren, mit dem es dunkler wird, aber damit sehen bspw. alle App Icons mies aus.
+1
MetallSnake
MetallSnake25.10.18 10:24
Paddy2590
Warum gibt es keinen vernünftigen Dark Mode für iOS? Bei den OLED Displays würde sich das doch richtig lohnen. Ja, ich weiß, es gibt Farben umkehren, mit dem es dunkler wird, aber damit sehen bspw. alle App Icons mies aus.

Der Homescreen wird damit aber doch gar nicht invertiert? Auch Bilder nicht.
Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.
0
Quickmix
Quickmix25.10.18 10:53
Fenvarien
Um die Frage gleich vorwegzunehmen: Wir prüfen momentan, wie wir das für MTN umsetzen können

+1
0
promac25.10.18 11:36
Paddy2590
Warum gibt es keinen vernünftigen Dark Mode für iOS?



0
Retrax25.10.18 16:49
Als Webdesigner empfiehlt es sich ein Farbschema auszuwählen unter Berücksichtigung von Benutzerfreundlichkeit, Gerbauchstauglichkeit sowie barrierearmer Zugänglichkeit bei welchem es letztlich egal ist wie der Nutzer seinen Desktop eingeichtet hat. Stichwort: Universalität.

Denn der Sinn obiger Themenbereiche ist es ja eine Webseite so zu entwickeln, dass diese eben "überall", d.h. unter Berücksichtigung jeglicher Nutzerszenarien funktioniert. Stichwort: Zeitlosigkeit.

Als Webentwickler / Webdesigner kann man nicht wissen, wie der User seinen Browser konfiguriert hat, welche persönlichen Stylesheets bspws. Verwendung finden um diese oder jene Behinderung des Nutzers "kleiner" in der Nutzung der Webeit zu halten.

Deshalb empfiehlt es sich als Entwickler sich von starren Vorgaben zu verabschieden und relative Einheiten zu verwenden und bzgl. der Farbwahl Tools wie z.B. nachfolgends zu verwenden:





Oder hat sich diesbezüglich die Annäherung an Barrierearmut und Gebrauchstauglichkeit mittlerweile geändert - sprich: gehört dieses Gedankengut mittlerweile zum Alteisen?
0
Retrax25.10.18 17:05
sierkb
Außerdem mit Safari Technology Preview 68 eingeführt ist der VP8 codec (die Nachfolgecodecs VP9 und AV1 werden sicher demnächst folgen):
Ach...

Ich weiss noch wie Apple bzw. Steve Jobs sich so vehement gegen die Implementierung von VP8 oder eine frühere Version des Codecs ausgesprochen hat und dies mit Copyright Problemen bzgl. der MPEG-Gruppe begründete...

Jetzt ein paar Jahre später...

Plötzlich ist vieles möglich.

Aber was wird denn jetzt vom W3C als Codec für die "video" und "audio" Tags präferiert?

Wir brauchen endlich einen universalen freien Codec.

Die MPEG-Gruppe hat doch H.264 imho unter bestimmten Voraussetzungen "freigegeben".

Und das ist auch der Codec welcher im Web Verbreitung gefunden hat.

Glaubst Du dass VP8 in dieser Hinsicht noch irgendeine Chance hat - gerade auch vor dem Hintergrund des Vorsprungs von H.264 bzgl. der sehr weit verbreiteten Hardware-Unterstützung?
0
sierkb25.10.18 18:29
Retrax
Ich weiss noch wie Apple bzw. Steve Jobs sich so vehement gegen die Implementierung von VP8 oder eine frühere Version des Codecs ausgesprochen hat und dies mit Copyright Problemen bzgl. der MPEG-Gruppe begründete...

Ist alles leeres, substanzloses Gewäsch und Marketing-Gebrabbel bzw. FUD gewesen. Inzwischen ist es eher umgekehrt: Microsoft und Apple aben sich den VPx- und dem Nachfolger AV1 zugewendet und machen da inzwischen mit, nicht nur, weil's qualitativ die bessere Wahl ist, sondern auch lizenz- und patentrechtlich die deutlich unproblematischere Wahl als die MPEG-Codecs (bzgl. H.264 sind die Lizenzen/Patente ja inzwischen abgelaufen, aber H.265/HVEC ist diesbzgl. eine einzige abschreckende, unkalkulierbare Modder- und Problemgrube, welche möglicherweise hoffnungslos verloren ist). Sieht selbst Leonardo Chiariglione, Gründer und Vorsitzender der MPEG in einem weltweit beachteten Blog-Post resigniert ein und stellt sogar die das Ende von MPEG in Aussicht:

Leonardo Chiariglione | Blog (04.02.2018): Can MPEG overcome its Video “crisis”?

Leonardo Chiariglione | Blog (28.01.2018): A crisis, the causes and a solution

Siehe dazu u.a. auch:

Golem (30.01.2018): Kaputtes Lizenzmodell: MPEG-Gründer sieht Videocodecs in Gefahr
Wegen eigener Probleme und der freien Konkurrenz der Aomedia sieht der Gründer der Moving Pictures Expert Group deren Lizenzmodell in Gefahr. Er zieht daraus den abwegigen Schluss, dass damit auch die Weiterentwicklung von Videocodecs gefährdet werde.
Golem
[…]
"Gute Geschichten haben ein Ende, so dass auch das MPEG-Geschäftsmodell nicht ewig überdauern kann", schreibt der Gründer der Moving Pictures Expert Group (MPEG), Leonardo Chiariglione, in seinem Blog. Als Grund dafür nennt Chiariglione einerseits die derzeit extrem verworrene Lizenzsituation für den MPEG-Codec HEVC alias H.265 und andererseits die sich abzeichnende starke freie Konkurrenz der Alliance for Open Media (Aomedia) mit dem kommenden Internet-Standard-Codec AV1.
[…]
Chiariglione schließt daraus: "Endlich wird allen klar, dass das alte MPEG-Geschäftsmodell bankrott ist, dass sich alle Investitionen (zusammen Hunderte Millionen US-Dollar) der Industrie für den neuen Video-Codec in Rauch auflösen werden und dass sich das kostenfreie Lizenzmodell der Aomedia auf andere Geschäftssegmente ausbreiten wird". Der Informatiker fügt noch an: "Die Situation kann als tragisch bezeichnet werden".

Zukunft der MPEG steht auf dem Spiel
[…]
Doch trotz dieser Überlegungen und Lösungsvorschläge betrachtet Chiariglione die Zukunft der MPEG alles andere als gut und befürchtet mit einem Ende der MPEG
[…]
Retrax
Jetzt ein paar Jahre später...
Plötzlich ist vieles möglich.

Wenn man nur will, die Scheuklappen ablegt und nicht im eigenen FUD gefangen bleiben will bzw. wenn man merkt, dass es teuer werden kann, wenn man den bisherigen Weg beibehält und ihn nicht verlässt, um sich neue Möglichkeiten zu eröffnen (Apple drängt ebenfalls ins Streaming-Geschäft, will da mitmischen, ist Inhalte-Anbieter geworden), ist vieles möglich.


Retrax
Aber was wird denn jetzt vom W3C als Codec für die "video" und "audio" Tags präferiert?
Wir brauchen endlich einen universalen freien Codec.

Gibt es inzwischen. Genau daran haben die Unternehmen (initiiert und federführend durch Google und Mozilla, Cisco, mit der Zeit sind immer mehr Unternehmen hinzugekommen und haben mitgemacht, u.a. Netflix, Microsoft und viele andere, mittlerweile hat sich dem sogar auch Apple angeschlossen) und Standardisierungs-Organisationen IETF und W3C jahrelang gearbeitet und die betreffenden Codecs optimiert: bzgl. Audio ist es der Opus-Codec, und weil die Zusammenarbeit da so gut geklappt hatte und was Gutes bei rausgekommen ist, hat man's bzgl. eines Video-Codecs gleich nochmal gemacht, und herausgekommen ist der AV1-Codec (Googles VP10-Codec als Basis, Mozilla/Xiphs Daala-Codec und Cisco's Thor-Codec bzw. das Beste aus allen 3 Codecs genommen, miteinander zu was Neuem gemacht und optimiert).
Retrax
Die MPEG-Gruppe hat doch H.264 imho unter bestimmten Voraussetzungen "freigegeben".

H.264 hat einen Nachfolger, und der heißt H.265/HVEC. Und der ist lizenz- und patentrechtlich eine einzige Katastrophe und MPEG/MPEG LA hat sich damit selbst ins Knie und ins Aus geschossen. Sicher mit ein Grund, warum schon seit ein längerem Microsoft sich den offenen und freien VPx-Codecs bzw. AV1 gegenüber geöffnet hat und da mitmacht und sich bei der Mit- und Fortentwicklung von AV1 einbringt, und für Apple wird ebenfalls diese katastrophale und unberechenbare lizenz- und patentrechtliche Situation von H.265/HVEC den Ausschlag gegeben haben, fortan nun ebenfalls endlich bei AV1 mitzumachen.
Retrax
Und das ist auch der Codec welcher im Web Verbreitung gefunden hat.

Kommt immer drauf an, wo man hinschaut und wessen Angebot man nutzt. Pauschal ist das nicht zu beantworten. Doch es ist derzeit wohl eher so, dass ein Trend ist, sich von den MPEG-Codecs wegzubewegen hin zu freien und lizenzkostenfreien Codecs, erst recht, was Streaming angeht (weil es da ganz schnell ins Geld geht bzw. u.U. sich zu horrenden Zahlungen summieren kann mit zahlreichen lizenzrechtlichen Fußangeln).
Retrax
Glaubst Du dass VP8 in dieser Hinsicht noch irgendeine Chance hat - gerade auch vor dem Hintergrund des Vorsprungs von H.264 bzgl. der sehr weit verbreiteten Hardware-Unterstützung?

Klar. Zumal auch dort schon längst eine breite in Chips gegossene Hardware-Unterstützung vorhanden ist, bei Apple vielleicht nicht, bei vielen anderen Herstellern hingegen schon lange sehr wohl, dafür haben verschiedene große Chip-Hersteller, die da alle mit im WebM/AOMedia-Boot sitzen, schon längst gesorgt und sorgen weiterhin dafür.

Zudem: VP8, VP9 sind verbreiteter als Du denkst (u.a. Youtube nutzt den standardmäßig), VP10 ist nie erschienen, sondern auf einer breiteren Basis und mit noch mehr Unterstützern in AV1 aufgagangen bzw. bildet eine der Säulen von AV1.

Golem (14.11.2014): IETF: VP8 und H.264 werden WebRTC-Standard
Der Streit um den Standard-Codec in WebRTC ist beigelegt. Sowohl das freie VP8 als auch H.264, das Patenten und Lizenzkosten unterliegt, müssen standardmäßig genutzt werden können. Die Details sind aber etwas komplizierter.

Wer WebRTC unterstützen will/muss, muss demnach beide Codecs unterstützen und kann/darf sich nicht damit begnügen, nur einen von beiden zu unterstützen, das ist im IETF-Standard bewusst so festgeschrieben (IETF und W3C arbeiten bzgl. der Standards eng zusammen), und genau deshalb jetzt auch Apples Schritt, auch VP8 anzubieten – weil es so festgeschrieben ist und sie qua Standard müssen, um größtmögliche Interoperabilität zu gewährleisten, das hat man beim Schreiben des Standards bewusst im Auge gehabt und beabsichtigt.
+1
Retrax26.10.18 07:43
sierkb
Wer WebRTC unterstützen will/muss, muss demnach beide Codecs unterstützen und kann/darf sich nicht damit begnügen, nur einen von beiden zu unterstützen, das ist im IETF-Standard bewusst so festgeschrieben (IETF und W3C arbeiten bzgl. der Standards eng zusammen), und genau deshalb jetzt auch Apples Schritt, auch VP8 anzubieten – weil es so festgeschrieben ist und sie qua Standard müssen, um größtmögliche Interoperabilität zu gewährleisten, das hat man beim Schreiben des Standards bewusst im Auge gehabt und beabsichtigt.

Ist das bei "macOS Mojave" schon der Fall?

Also jetzt nicht auf der Terminal Ebene sondern ich möchte bspws. einfach über den Quicktime Player dann AV-1 und OPUS exportieren können.

Geht das?
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.