Hatte heute ein Ticket aufgemacht, aber das sollte ein Duplikat von dem sein, ja. Kommt auch zeitlich mit dem Landen von
SessionHistoryInParent hin.
Entwicklung Firefox
-
pcinfarkt -
15. August 2009 um 20:46 -
Erledigt
-
-
Eben in der Nightly gesehen, ist das schon bekannt?
ZitatCSS: Constructable Stylesheets
Durch das Hinzufügen eines Konstruktors zur CSSStyleSheet-Schnittstelle sowie einer Vielzahl damit zusammenhängender Änderungen können direkt neue Stylesheets erstellt werden, ohne dass das Sheet dem HTML hinzugefügt werden muss. Das macht es viel einfacher, wiederverwendbare Stylesheets für den Einsatz mit Shadow DOM zu erstellen. Weitere Informationen erhalten Sie im Bug 1520690.
Sollte man echt jetzt an die shadow-Elemente rankönnen?
rel=preload kann man hoffentlich abschalten später, ich mag kein Vorausladen von Seiten, die ich eh nicht besuche.
-
Sollte man echt jetzt an die shadow-Elemente rankönnen?
Ich bin mir nicht sicher, was genau das meint, aber das Shadow DOM CSS konnte ja bereits von außen verändert werden: https://developer.mozilla.org/en-US/docs/Web/CSS/::part. Von der Datei userChrome.css wird das nicht unterstützt, daran ändert sich mit Constructable Stylesheets aber auch nichts. Auf https://developers.google.com/web/updates/20…ble-stylesheets findet man eine Erklärung, was Constructable Stylesheets sind. Für Webentwickler sicher interessant, aber wirklich nur für die.
rel=preload kann man hoffentlich abschalten später, ich mag kein Vorausladen von Seiten, die ich eh nicht besuche.
Kann man, ich würde Performance-Verbesserungen aber nicht abschalten. Es werden damit keine beliebigen Seiten vorausgeladen, sondern Ressourcen (Schriften, CSS, Bilder, JS), die sowieso geladen würden. Dieser Mechanismus gibt Entwicklern mehr Kontrolle darüber, Anfragen zu priorisieren, um so die Geschwindigkeit zu optimieren.
-
Von der Datei userChrome.css wird das nicht unterstützt, daran ändert sich mit Constructable Stylesheets aber auch nichts.
Verd..., so ein Mist aber auch. Das mit preload, dann mag ich auch keine sonstigen Teile laden wollen
-
Wie gesagt, rel=preload lädt nichts, was nicht sowieso geladen wird. Alles andere würde aus Entwickler-Sicht keinen Sinn ergeben, weil es dann nachteilig wäre. Eine Deaktivierung des Features bringt dir eine minimal verschlechterte Geschwindigkeit, ansonsten gar nichts. Daher würde ich mich auch nicht darauf verlassen, dass es die Einstellung, die es zur Deaktivierung gibt, für immer geben wird.
-
was nicht sowieso geladen wird
Ich habe Vorausladen hier explizit abgeschaltet (alle Browser), weder für Seiten auf dem gleichen Server noch von anderen Servern. Ich mag das nicht, ich will das nicht. Wer das als Entwickler benötigt, bitte.
-
Die Aussage "Wer das als Entwickler benötigt" ergibt ja mal null Sinn. Der Entwickler hat doch nichts davon, der Nutzer profitiert davon. Genauso wenig Sinn ergibt, was du implizit damit aussagst, nämlich dass du nicht magst, wenn Websites schneller laden. Deine Aussage hat schon viel von reflexartiger Reaktion auf einen Begriff, ohne den technischen Hintergrund überhaupt verstanden zu haben. Die Anweisung signalisiert dem Browser lediglich, welche Ressourcen er priorisieren soll (und das ist auch nicht verbindlich), um sie bereits in den Browser-Cache zu laden, weil sie als erstes benötigt werden. Aber beim letzten Wort schließe ich mich dir an: Bitte. Wenn du so denkst: Bitte, dein gutes Recht. Nur wie gesagt glaube ich nicht, dass es dauerhaft möglich sein wird, das abzuschalten, weil es einfach keinen Anwendungsfall dafür gibt. Du hast offensichtlich eine völlig falsche Vorstellung von dieser Funktion.
-
Du hast das mit dem Entwickler eingeworfen, mag sein, dass es hier falsch angekommen ist:
ZitatAlles andere würde aus Entwickler-Sicht keinen Sinn ergeben
Dass die Leute rund um Firefox wohl hauptsächlich Entwickler sind, war das klar, daher bin ich von Entwicklern mit/für Firefox ausgegangen, also Erweiterungen und co. Webseiten hatte ich nicht im Sinn.
ZitatWeb API: <link rel="preload">
Das rel-Attribut mit dem Wert "preload" in einem <link>-Element soll dazu beitragen, Leistungssteigerungen zu erzielen, indem Sie Ressourcen früher im Seitenlebenszyklus herunterladen, damit sie früher verfügbar sind und weniger wahrscheinlich das Rendern von Seiten blockieren. Lesen Sie Preloading content with rel="preload" oder Bug 1583604 für weitere Details.
ZitatDie Anweisung signalisiert dem Browser lediglich, welche Ressourcen er priorisieren soll (und das ist auch nicht verbindlich), um sie bereits in den Browser-Cache zu laden, weil sie als erstes benötigt werden.
Das ist für mich nicht eines. Und diese Seite erklärt es noch anders:
https://developer.mozilla.org/docs/Web/HTML/Preloading_content
Hier wird im head deklariert, was weiter unten benötigt wird. Das ist wohl die Langfassung vom Text in der Nightly, die sich wesentlich verständlicher liest als die Kurzfassung in Firefox/Einstellungen. So gesehen ist deine Aussage näher an MDN ran als die von Firefox dazu.
Im Bereich Video/Audio werd ich mir dann ein Userscript schrauben, um das zu verhindern, alle anderen Ressourcen sind ok.
-
Du hast das mit dem Entwickler eingeworfen, mag sein, dass es hier falsch angekommen ist
Der Entwickler einer Website muss entsprechende Anweisung in den Code einbauen, schließlich geht es hier um ein HTML-Feature. Aber kein Entwickler "benötigt das", es geht um eine Geschwindigkeits-Optimierung für den Endnutzer.
Dass die Leute rund um Firefox wohl hauptsächlich Entwickler sind, war das klar, daher bin ich von Entwicklern mit/für Firefox ausgegangen, also Erweiterungen und co. Webseiten hatte ich nicht im Sinn.
Zur Klarstellung, weil ich mir nicht sicher bin, ob es klar ist: Ich habe in diesem Zusammenhang nicht von Firefox-Entwicklern gesprochen. Als HTML-Feature betrifft dieses Feature Websites und ich meinte, dass es aus Sicht des Website-Entwicklers keinen Sinn ergeben würde, dem Browser zu signalisieren, dass eine Ressource vorausgeladen werden solll, die nicht sowieso geladen werden muss. Denn dann würde aus der Performance-Optimierung ja eine Performance-Verschlechterung werden, weil zusätzliche Inhalte geladen werden. Darum kann man ziemlich sicher annehmen, dass hierdurch nichts geladen wird, was nicht sowieso geladen wird. Nur eben früher im Ladezyklus der Website.
Das ist für mich nicht eines. Und diese Seite erklärt es noch anders: […] So gesehen ist deine Aussage näher an MDN ran als die von Firefox dazu.
Inhaltlich steckt da eigentlich nicht wirklich anderes dahinter. Mir fällt auf, dass du in deinem Zitat "in einem <link>-Element" fett markiert hast. Vielleicht liegt hier das Missverständnis vor: Ein <link>-Element ist kein Link auf eine andere Seite. MDN formuliert das so: "Das HTML-Link-Element (<link>) spezifiziert Beziehungen zwischen dem aktuellen Dokument und einer externen Ressource." In dem Fall bedeutet das, dass die Anweisung zum Preloading eben über ein <link>-Element stattfindet. Es geht aber immer um einzelne Ressourcen, sprich Schriften, Bilder, Scripts, CSS, …
Im Bereich Video/Audio werd ich mir dann ein Userscript schrauben, um das zu verhindern, alle anderen Ressourcen sind ok.
Du sprichst hier in der Zukunft, tatsächlich gibt es aber speziell für Video- und Audio-Elemente bereits seit zig Jahren ein preload-Attribut direkt im jeweiligen Element. Und wenn du dafür noch kein Script hast, erlaubst du das schon seit vielen Jahren.
-
Ist mir in der Tat noch nicht aufgefallen, danke für den Hinweis. Was ich wohl schon nutze gegen eingebundene Videos:
https://greasyfork.org/en/scripts/370-stop-overzealous-embedding
Das betrifft aber nicht Videos via HTML5. Alles nur eine Frage der Zeit.
-
Der Fission-Meilenstein M6b hat auch nur noch fünf offene Tickets für das Fission-Experiment (standardmäßige Aktivierung für einen Teil der Nightly-Nutzer), 110 offene Tickets für M6c (Nightly) und 218 offene Tickets für M7 (Beta-Experiment). Es geht vorwärts.
Der Meilenstein M6b ist nun abgeschlossen, womit Firefox bereit für das Fission-Experiment ist. Noch 92 offene Tickets für M6c und 224 offene Tickets für M7 (Beta-Experiment).
In dem Zusammenhang möchte ich nochmal auf about:processes hinweisen, was in den letzten Wochen einige Verbesserungen erhalten hat
-
Wenn das aktuelle Modell soweit "rund" ist, was ist dann der weitere Plan? Wird die Site Isolation dann wie bei Chromium noch weiter verfeinert oder soll es erstmal auf der Stufe bleiben?
Für Fenix ist das noch nicht absehbar, oder? Das letzte Mal als ich nachschaute hat Fenix immer noch nur einen Web Content-Prozess genutzt, also ist noch nicht mal e10s dort aktiv.
-
Bis auf Frame-Ebene ist ja schon ziemlich fein unterteilt. Wie würdest du das noch weiter verfeinerrn beziehungsweise was macht Chromium darüber hinaus?
e10s-multi und Fission sind definitiv ein Thema für Fenix, aber wenn du "absehbar" auf die nächsten paar Monate beziehst, würde ich das als sehr unwahrscheinlich einschätzen. Aber dass ein Ticket eröffnet worden ist, um e10s-multi in der Nightly-Version zu aktivieren, ist jetzt auch gerade mal drei Monate her (https://bugzilla.mozilla.org/show_bug.cgi?id=1654817), was zwar nicht heißt, dass eine Auslieferung nahe wäre, aber zumindest dafür spricht, dass das Thema noch aktuell ist. Und aktive Arbeit findet auch statt wie zum Beispiel in https://bugzilla.mozilla.org/show_bug.cgi?id=1668376, die Tage erst behoben.
-
Für Chromium gibt es hier den aktuellen Stand: https://www.chromium.org/developers/des…C-Project-Tasks
Für Firefox habe ich leider nichts ähnlich detailliertes und nach außen verständliches gefunden. Ein großer Unterschied ist meines Wissens, dass Firefox alle Seiten eines Origins in einen Prozess packt, während Chromium zumindest bei genügend RAM möglichst auch gleiche Origins in einzelne Prozesse packt.
Wobei man da mittlerweile auch in Limits zu laufen scheint, insbesondere RAM-Verbrauch und zu viel IPC-Overhead durch die hohe Prozessanzahl. Unter Android ist die Site Isolation auch deutlich zurückgefahren, aber immerhin vorhanden.
Wobei Fenix da noch größere Probleme zu haben scheint, mir zerschießt es momentan gerne öfter mal den Web-Prozess, was sich dann zB darin äußert, dass die Tastatur in Fenix kaputt ist. Mozilla ist das wohl bekannt, aber man scheint da noch keine wirklich gute Lösung zu haben.
-
Warum wurde nach Jahren (!) Strg+Umschalt+B auf Strg+Umschalt+O verlegt, wie in Chrome, was soll der Blödsinn?
-
Weil man Strg+Umschalt+B benötigt hat, um die Lesezeichen-Symbolleiste ein- und auszublenden, was bisher überhaupt nicht via Tastatur möglich war und in Zukunft an Relevanz gewinnen wird, da Firefox bald die Lesezeichen-Symbolleiste als Teil der Firefox-Startseite anzeigen wird. Das ist Teil von einer ganzen Reihe von Lesezeichen-Verbesserungen, an denen Mozilla derzeit arbeitet.
Klar hätte man es auch umgekehrt belegen können, aber sich einen Shortcut mit anderen Browsern zu teilen, ist ein klarer Nutzer-Vorteil, weil sich Nutzer nicht für jeden Browser einen anderen Shortcut merken müssen. Und wir sprechen hier ausdrücklich nicht nur von Chrome, sondern mindestens auch noch von Safari, der ebenfalls diese Tasten verwendet.
-
Weil man Strg+Umschalt+B benötigt hat, um die Lesezeichen-Symbolleiste ein- und auszublenden, was bisher überhaupt nicht via Tastatur möglich war
Ich hätte ja noch Verständnis, wenn man es jetzt "international" haben will, aber was du mir versuchst zu sagen, heisst für mich nur, dass irgendjemand den Browser respektive das deutsche Sprachmodul nicht gut genug kennt. Denn Ctrl+B ist auch in Englisch so, und da kommt B von Bookmarks und H von History
https://support.mozilla.org/en-US/kb/keybo…x-tasks-quickly
Wie Google auf den Mumpitz mit ctrl shift o für die Lesezeichen gekommen ist, selbst für den IE ist es ctrl + b für die Lesezeichenverwaltung und Ctrl + shift + b für die Lesezeicheleiste.
Da dürfte sich der nächste Shitstorm anbahnen. Und ich werd mir wohl eine andere Sprachdatei basteln.
-
Ich habe von der Symbolleiste, nicht von der Sidebar gesprochen.
Den zweiten Absatz verstehe ich nicht, weil das mit der deutschen Version nicht das Geringste zu tun hat, sondern, wie ich bereits erklärte, damit, dass sich Nutzer zwischen den verschiedenen Browsern nicht umgewöhnen müssen.
Jemanden zu beleidigen (Beitrag wurde angepasst) ist völlig überflüssig.
-
Ich habe den Text oben geändert, weil ungenau gelesen, du meinst die Leiste, ich war gedanklich bei der Sidebar. Mein Fehler. Das mit dem Ochsen lass ich dennoch so stehen, hätte man auch anders lösen können, auch wenn es dir nicht gefallen mag. Seit Phoenix war das so, mit mal fällt einem () ein, alles über den Haufen zu werfen.
-
Das mit dem Ochsen lass ich dennoch so stehen, hätte man auch anders lösen können, auch wenn es dir nicht gefallen mag.
Gut, dann hab ich das jetzt für dich erledigt und die Beleidigung aus deinem Beitrag entfernt. Die Forenregeln bestimmst nicht du - und die schützen nicht nur Menschen, welche hier registriert sind.
Seit Phoenix war das so, mit mal fällt einem () ein, alles über den Haufen zu werfen.
Dass es jetzt eine Änderung gibt, hängt mit dem zusammen, was ich bereits erklärte: Nämlich, dass es gerade einen Fokus auf Verbesserungen der Lesezeichen gibt und dass es in diesem Zusammenhang eine ganze Reihe von Veränderungen in Bezug auf Lesezeichen gibt. Diesen Fokus gab es nicht vor fünf Jahren, nicht vor zwei Jahren, den gab es auch nicht vor einem halben Jahr, den gibt es jetzt. Und weil es diesen Fokus jetzt gibt, werden gewisse Lesezeichen-Themen, die schon älter sind, aber bislang nicht angegangen wurden, jetzt umgesetzt.
Dir gefällt die Änderung nicht, was auch vollkommen okay ist, aber deswegen darf man nicht denken, dass das jeder blöd finden würde. Auch wenn die Votes auf BMO für Mozilla keine besondere Relevanz besitzen, wird diese Funktion von Nutzern genutzt und mit 20 Votes, auch wenn das nicht extrem viele sind, sind das immer noch für BMO überdurchschnittlich viele Votes, die das bereits vier Jahre alte Ticket erhalten hat, welches die Einführung einer eines Shortcuts für die Lesezeichen-Symbolleiste betrifft. Möchte man einen Shortcut implementieren, muss man schauen, was noch frei ist - und es ist teilweise extrem schwierig, freie Kombinationen zu finden -, aber auch, wie es andere Browser lösen, denn wie gesagt ist das ein klarer Vorteil im Sinne der Nutzer, wenn diese nicht für jeden Browser etwas anderes lernen müssen. Und in besagtem Ticket auf BMO waren es auch reale Nutzer, die sich explizit gewünscht haben, dass Mozilla den gleichen Shortcut wie Chrome nutzt. Und wie gesagt nicht nur Chrome, mindestens auch Safari, wahrscheinlich nutzen die ganzen auf Chromium basierenden Browser ebenfalls diesen Shortcut (ungeprüft).
Als Firefox-Nutzer, der bislang eine Tastenkombination im Kopf hatte, mag das eine Umgewöhnung sein, klar. Aber bitte, worüber sprechen wir hier? Nichts wurde entfernt, nur eine Tastenkombination geändert. Daran gewöhnt man sich schnell und der Vorteil überwiegt hier in meinen Augen ganz klar. Ich möchte sogar sagen, dass je niedriger der Marktanteil von Firefox wird, desto mehr der Vorteil überwiegt, weil das auch bedeutet, dass es relativ betrachtet immer mehr Menschen sind, welche eine bestimmte Erwartung haben und dann, wenn sie Firefox ausprobieren, entweder Erfolg haben oder denken, dass Firefox das nicht kann.
