Warum zeigen Websites heutzutage ihren Text nicht sofort an?

444

Mir ist aufgefallen, dass in letzter Zeit auf vielen Websites der Text nur langsam angezeigt wird. Normalerweise werden der Hintergrund, Bilder usw. geladen, aber kein Text. Nach einiger Zeit erscheint der Text hier und da (nicht immer alles zur gleichen Zeit).

Es funktioniert im Grunde umgekehrt, als der Text zuerst angezeigt wurde, dann die Bilder und der Rest wurde danach geladen. Welche neue Technologie schafft dieses Problem? Irgendeine Idee?

Beachten Sie, dass ich eine langsame Verbindung habe, was das Problem wahrscheinlich noch verstärkt.

Ein Beispiel finden Sie unten - alles ist geladen, aber es dauert noch ein paar Sekunden, bis der Text schließlich angezeigt wird:

Bildbeschreibung hier eingeben

laurent
quelle
72
In diesem speziellen Fall verwendet PortableApps.com die Schriftart "Ubuntu". John hat zuerst OpenSans ausprobiert, aber wir sind ziemlich schnell zu Ubuntu gewechselt. Ich war der Hauptbefürworter des Wechsels ... Eine Möglichkeit, das Problem zu beheben, besteht darin, die Schriftfamilie selbst installieren zu lassen. Wenn Sie es von font.ubuntu.com installieren, funktioniert es sofort.
Chris Morgan
21
Die Antwort von Daniel ist ein Augenöffner. Ich dachte, das ist absichtlich so, damit wir alle Anzeigen auf der Seite sehen können.
Manoj R
1
Wie hier bereits von mehreren Personen ausgeführt wurde, gibt es unzählige Gründe, warum Text auf unerwartete Weise gerendert wird, da das Rendern einer Seite nur durch die Vorstellungskraft des Entwicklers / Designers eingeschränkt ist, was zumindest der Fall war, seit ANSI-Positionscodes das Bulletin der 1980er Jahre zuließen Boards zur Implementierung von Mehrbenutzer-Chats und Benutzeroberflächen mit überlappenden Fenstern mit Schlagschatten. Meebo war einer der Ersten, der einige dieser Effekte in einem Browser ohne Applet reproduzierte. "Funktioniert im Gegenteil wie früher" vereinfacht das Internet erheblich und bezieht sich nicht einmal auf einen bestimmten Zeitraum.
PJ Brunet
6
Warum also pauschale Verallgemeinerungen über das Internet machen, die auf einer zufälligen Bildschirmbegrenzung einer Website mit einem niedrigen Alexa-Rang basieren? Die beste Antwort ist auch eine kühne Behauptung: "Heutzutage machen Designer XYZ" sollte mit einigen reellen Zahlen gestützt werden, wie "5% der Websites verwenden ab 2012 Google Web Fonts" oder was auch immer es ist.
PJ Brunet
1
Aber Schriftdateien werden im Cache gehalten, diese Seite hat lange auf das Laden von m.aspx gewartet, sie könnten diesen Teil überprüfen
user613326

Antworten:

483

Ein Grund dafür ist, dass Webdesigner heutzutage gerne Webfonts (normalerweise im WOFF- Format) verwenden, z. B. über Google Webfonts .

Bisher konnten nur die vom Benutzer lokal installierten Schriftarten auf einer Site angezeigt werden. Da z. B. Mac- und Windows-Benutzer nicht unbedingt die gleichen Schriftarten hatten, definierten Designer instinktiv immer Regeln wie

font-family: Arial, Helvetica, sans-serif;

Wäre die erste Schriftart nicht auf dem System vorhanden, würde der Browser nach der zweiten und schließlich nach einer "serifenlosen" Ersatzschrift suchen.

Jetzt kann man eine Schriftart-URL als CSS-Regel angeben, damit der Browser eine Schriftart als solche herunterlädt:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

und laden Sie dann die Schriftart für ein bestimmtes Element, z. B .:

font-family: 'Droid Serif',sans-serif;

Dies ist sehr beliebt, um benutzerdefinierte Schriftarten verwenden zu können, es führt jedoch auch zu dem Problem, dass kein Text angezeigt wird, bis die Ressource vom Browser geladen wurde, einschließlich der Downloadzeit, der Ladezeit der Schriftarten und der Renderzeit. Ich gehe davon aus, dass dies das Artefakt ist, das Sie erleben.

Als Beispiel: Eine meiner nationalen Zeitungen, Dagens Nyheter , verwendet Web-Schriftarten als Überschriften, nicht jedoch als Ableitungen. Wenn diese Site geladen wird, werden in der Regel die Ableitungen zuerst und eine halbe Sekunde später alle darüber liegenden Leerzeichen ausgefüllt mit Schlagzeilen (dies gilt zumindest für Chrome und Opera. Habe noch keine anderen ausprobiert).

(Außerdem streuen Designer JavaScript heutzutage absolut überall hin, also versucht vielleicht jemand, etwas Kluges mit dem Text zu machen, weshalb er verzögert wird. Das wäre jedoch sehr site-spezifisch: Die allgemeine Tendenz, dass sich der Text in diesen verzögert Mal ist das oben beschriebene Webfont-Problem, glaube ich.)


Zusatz

Diese Antwort wurde sehr positiv aufgenommen, obwohl ich nicht sehr ins Detail gegangen bin, oder vielleicht deswegen . Da der Fragenthread viele Kommentare enthält, werde ich versuchen, ihn ein wenig zu erweitern (viele Kommentare scheinen kurz nach dem Schutz des Themas verschwunden zu sein - einige Moderatoren haben sie wahrscheinlich manuell bereinigt). Lesen Sie auch die anderen Antworten in diesem Thread, da sie alle auf ihre eigene Weise erweitert werden.

Das Phänomen ist anscheinend allgemein als "Flash eines nicht gestalteten Inhalts" und insbesondere als "Flash eines nicht gestalteten Texts" bekannt. Suche nach "FOUC" und "FOUT" gibt weitere Informationen.

Ich kann den Beitrag von Webdesigner Paul Irish auf FOUT im Zusammenhang mit Webfonts empfehlen .

Was man beachten kann ist, dass verschiedene Browser dies unterschiedlich behandeln. Ich habe oben geschrieben, dass ich Opera und Chrome getestet habe, die sich beide ähnlich verhalten haben. Alle WebKit-basierten (Chrome, Safari usw.) vermeiden FOUT, indem sie während des Ladezeitraums für Web-Schriftarten keinen Web-Schrifttext mit einer Ersatzschrift rendern. Selbst wenn die Webschrift zwischengespeichert wird, kommt es zu einer Renderverzögerung . Es gibt viele Kommentare in diesem Fragenthread, in denen etwas anderes gesagt wird, und dass es absolut falsch ist, dass sich zwischengespeicherte Schriften wie folgt verhalten, aber z. B. über den obigen Link:

In welchen Fällen erhalten Sie eine FOUT

  • Will: Herunterladen und Anzeigen eines Remote-TTF / OTF / Woff
  • Will: Zeigt ein zwischengespeichertes ttf / otf / woff an
  • Will: Herunterladen und Anzeigen eines Daten-Uri-TTF / OTF / Woff
  • Will: Anzeige eines zwischengespeicherten Daten-Uri-TTF / OTF / Woff
  • Wird nicht: Anzeigen einer Schriftart, die bereits installiert und in Ihrem traditionellen Schriftstapel benannt ist
  • Wird nicht: Anzeigen einer Schriftart, die unter Verwendung des lokalen () Speicherorts installiert und benannt ist

Da Chrome vor dem Rendern wartet, bis das FOUT-Risiko beseitigt ist, tritt eine Verzögerung ein. Zu welchem Ausmaß die Wirkung sichtbar ist (vor allem , wenn aus dem Cache geladen) scheint unter anderem die Menge an Text abhängig zu sein, und vielleicht auch andere Faktoren gemacht werden muss, aber das Caching nicht vollständig entfernt den Effekt.

Irish hat am Ende des Beitrags auch einige Aktualisierungen zum Browserverhalten (Stand 2011/04/14) veröffentlicht:

  • Firefox (ab FFb11 und FF4 Final) hat keine FOUT mehr! Wooohoo! http://bugzil.la/499292 Grundsätzlich ist der Text 3 Sekunden lang unsichtbar und bringt dann die Ersatzschrift zurück. Das Webfont wird wahrscheinlich innerhalb dieser drei Sekunden geladen ... hoffentlich ...
  • IE9 unterstützt WOFF und TTF und OTF (obwohl es eine eingebettete Bit- Set-Sache erfordert - meistens streitig, wenn Sie WOFF verwenden). JEDOCH!!! IE9 hat einen FOUT. :(
  • Webkit hat einen Patch, der darauf wartet, nach 0,5 Sekunden als Ersatztext angezeigt zu werden. Also dasselbe Verhalten wie FF, aber 0,5s statt 3s.
  • Ergänzung : Blink hat auch dafür einen Fehler registriert , aber es scheint, dass noch kein endgültiger Konsens darüber erzielt wurde, was damit zu tun ist - derzeit dieselbe Implementierung wie WebKit.

Wenn dies eine Frage für Designer wäre, könnte man nach Wegen suchen, um solche Probleme zu vermeiden webfontloader, aber das wäre eine andere Frage. Der Paul Irish Link geht auf diese Angelegenheit näher ein.

Daniel Andersson
quelle
7
Hat einer der Browser versucht, den Text zuerst in einer verfügbaren Schriftart und nach dem Herunterladen der bevorzugten Schriftart erneut zu rendern?
Steve Bennett
4
Oh, duh, kommentieren Sie die nächste Antwort: paulirish.com/2009/fighting-the-font-face-fout
Steve Bennett
5
@ratchetfreak es wäre beunruhigend, wenn die Seite neu formatiert würde, da die Schriftarten wahrscheinlich nicht die gleichen Metriken haben würden
Samuel Edwin Ward
6
Einige würden es vorziehen, zum Lesen einer Webseite zu gehen, anstatt lange darauf zu warten, dass die Schrift geladen wird
Ratschenfreak
@SteveBennett Ich bin mir ziemlich sicher, dass Internet Explorer 10 genau das tut. Ich habe noch nie gesehen, dass Text später auftauchte. Für mich ist es immer Text, der in einer "Standardschriftart" erscheint, und einige Sekunden später ändert er sich in die gestaltete / heruntergeladene. Ich bin nicht sicher, ob es das nächste CSS oder nur die Standardeinstellung des Systems auswählt. Edit: Ah, schön, also ist es nur Webikit mit dem versteckten Text? Ich würde dieses nervige und schlechte Benehmen als etwas bezeichnen. Gibt es einen Browser, der das progressive Laden von Bildern ignoriert oder versteckt?
Mario
117

Der Grund dafür ist der Text , den Sie noch nicht lesen kann , wird mit gerendert wird eine Web - Schriftart , die nach unten die Rohre an Ihren Browser immer noch auf dem Weg ist.

Da es sich bei Ihrem Browser um Google Chrome handelt, das WebKit zum Rendern der Seite verwendet, wurde von diesen entschieden (das heißt, WebKit), dass Sie am besten überhaupt keinen Text sehen, bis die Webschrift heruntergeladen ist. Wenn Sie jedoch ein Entwickler sind, der den Text lieber in einer geeigneten Fallback-Systemschrift lesen möchte , können Sie dies mit dem WebFont Loader von Google erreichen.

Marcel
quelle
Leider ist es eine falsche Antwort. Wenn Sie diese Seite einmal besuchen, befindet sich die Schriftartdatei in Ihrem Web-Cash. Für andere Seiten auf dieser Website oder auf anderen Websites, die diese Schriftart verwenden, wird sie aus Bargeld abgerufen.
user613326
19

Kurze Antwort: Ajax oder Wuff

Es gibt verschiedene Gründe dafür, dass Websites "nur langsam ihren Text anzeigen" . Die Langsamkeit auf portableapps.com wird durch das Herunterladen von WOFF- Schriftarten verursacht. Was Sie jedoch als "Text beginnt hier und da zu erscheinen" beschreiben, wird häufiger von AJAX verursacht .

Eine Website besteht aus vielen Teilen. Wie diese Teile heruntergeladen und zusammengestellt werden, hängt von der Designauswahl des Webdesigners ab . Die Langsamkeit wird dadurch verursacht, wie der Entwickler die folgenden Bausteine ​​zusammensetzt:

  • Anfängliche HTML-Seite
  • CSS
  • JS
  • Bilder
  • WOFF-Schriften
  • AJAX-Anfragen
  • DOM-Manipulation

Traditionell Websites:

Traditionell war es für Entwickler üblich, den Textinhalt in die ursprüngliche HTML-Seite einzufügen und anzuzeigen, sobald er verfügbar war . Der HTML-Code verweist auf mehrere Ressourcen, die dann heruntergeladen werden. Der Browser zeichnete den Bildschirm dann nach und nach neu , um die Stile und Bilder einzuschließen, sobald sie verfügbar wurden. AJAX und WOFF waren nicht verfügbar.


WOFF Websites:

Mit WOFF-Schriftarten kann eine Website Schriftarten verwenden, die dem Browser normalerweise nicht zur Verfügung stehen, indem sie Schriftarten mit der Website herunterlädt . Einige Entwickler weisen den Browser an, den Textinhalt erst dann anzuzeigen, wenn alle WOFF-Schriftarten heruntergeladen wurden. Meiner Erfahrung nach ist dieser Ansatz noch nicht sehr verbreitet.


AJAX-Websites:

Einige Entwickler entscheiden sich dafür, den Textinhalt nicht in die ursprüngliche HTML-Seite aufzunehmen. Stattdessen laden sie den Textinhalt mit AJAX herunter. Dies geschieht nach dem Laden der Basisseite . Nach meiner Erfahrung hat diese Methode eine viel breitere Verbreitung als WOFF-Schriften und ist häufig die Ursache für die von Ihnen beschriebene Langsamkeit.


Feststellung der Ursache

Um die Ursache für eine bestimmte Site zu ermitteln, ist eine Analyse mit Tools wie Firebug oder Chrome Developer Tools erforderlich . Alternativ können Sie die Site mit Internet Explorer 8 öffnen , der AJAX, jedoch nicht WOFF unterstützt. Wenn die Site immer noch langsam ist, liegt das Problem bei AJAX und nicht bei WOFF.

KevSheedy
quelle
14

Oft ist es eine bewusste Entscheidung, das "Aufblitzen von nicht gestylten Inhalten" zu vermeiden. Wenn der vor dem Laden des CSS angezeigte Text kurz als unformatiert angezeigt wird, wird beim Neuzeichnen durch den Browser ein Flash angezeigt. Durch das Einfügen einiger grundlegender Inline-Stile zum anfänglichen Ausblenden des Inhalts, der im tatsächlichen Stylesheet überschrieben wird, oder durch die Verwendung von JS wird dieser Flash vermieden.

Greg H
quelle
6
In neun von zehn Fällen ist dies nicht beabsichtigt, sondern lediglich ein Nebeneffekt der einfachsten Art, Web-Schriften einzubetten. Tatsächlich ist ein wenig mehr Aufwand erforderlich, um eine sichtbare Alternative zu präsentieren, während die Web-Schriftarten auf dem Vormarsch sind. Siehe developers.google.com/webfonts/docs/webfont_loader
Marcel
@Marcel - dies kann als auch langsame Schriftarten durch langsame Sheets verursacht werden, siehe phpied.com/css-and-the-critical-path
r3m0t
Code, der das "Aufblitzen nützlicher Inhalte" verhindert, verhindert in der Regel, dass sowohl Bilder als auch Text angezeigt werden.
Jon Hanna
Ich kann nicht verstehen, warum nicht gestylter Text schlechter ist als gar kein Text. Ich möchte lieber in der Lage sein, ein Accept zu lesen, das vielleicht ein bisschen wackelt. Ich finde es nervöser, wenn es plötzlich aus dem Nichts auftaucht und es sehr frustrierend ist, wenn eine Seite geladen wurde und Sie gezwungen sind, auf eine Schriftart zu warten.
Richard Le Poidevin
8

Wie andere angemerkt haben, tragen benutzerdefinierte Schriftarten wahrscheinlich zur Verzögerung bei.

Um etwas mehr Hintergrund zu geben, geht der Browser ungefähr so ​​vor, bevor er den Seiteninhalt auf dem Bildschirm rendern kann:

  1. HTML holen (mehrere Roundtrips für DNS, TCP, Request / Response)
  2. Beginnen Sie mit dem Parsen von HTML, und entdecken Sie externe Ressourcen wie externes CSS und JS. Beachten Sie, dass CSS das Layout und JS das Parsen blockiert. Externe Ressourcen wie CSS und JS, die zu Beginn des Dokuments geladen wurden (z. B. im Kopf), verlangsamen die Zeit, die eine Seite benötigt, um Inhalte auf dem Bildschirm anzuzeigen.
  3. Abrufen von externem CSS und JS (mehrere Roundtrips: DNS und TCP, wenn sich diese Ressourcen in einer anderen Domäne befinden, z. B. CDN, sowie eine RTT für die Anforderung / Antwort)
  4. Sobald das externe CSS und JS fertig geladen sind, analysieren / führen Sie JS aus und analysieren / wenden Sie Stile an
  5. Wenn das CSS auf benutzerdefinierte Schriftarten verweist, müssen diese Schriftarten jetzt ebenfalls heruntergeladen werden, was zu zusätzlichen Roundtrip-Verzögerungen beim Rendern von Teilen der Seite führt, die von den benutzerdefinierten Schriftarten abhängen

Obwohl es nicht um Verzögerungen geht, die speziell durch benutzerdefinierte Schriftarten verursacht werden, habe ich kürzlich einen Blog-Beitrag verfasst, der zusätzliche Informationen zu den Ursachen von Render-Verzögerungen enthält. Es gibt einige Vorschläge, um die Zeit für das erste Malen Ihrer Seiten zu minimieren. Dies ist hoffentlich hilfreich für Leser, die Inhalte auf ihren Seiten schneller anzeigen möchten, einschließlich der Seiten, die benutzerdefinierte Schriftarten verwenden möchten: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -eine Sekunde/

Bryan McQuade
quelle
4

Kurze Antwort: Entwickler.

Wenn Verknüpfungs- und Skript-Tags, die auf externe Dokumente verweisen (z. B. CSS- oder JS-Dateien), im Kopf des Dokuments platziert werden (höher im Fluss als der Textkörper und seine Elemente), werden sie zuerst geladen. JavaScript wird aus dem Markup ausgeführt, das darauf verweist. wenn viel Code zu verarbeiten ist oder es sich um umständlichen Code handelt oder wenn der erwartete Text auf einem Server gerendert und beim Laden in das Dokument eingefügt wird - und dieser serverseitige Code auch umständlich ist, Bei großen oder blockierenden E / A-Vorgängen, die auf die Verarbeitung mehrerer gleichzeitiger Anforderungen zurückzuführen sind, kann es zu Ausfallzeiten kommen, bevor der HTML-Code überhaupt gerendert werden konnte. Einige Entwickler wählen das Laden von nicht mit der Ansicht in Zusammenhang stehendem JavaScript nach dem Markup und den Stilen (am Ende des Texts).

Die Geschwindigkeit der Internetverbindung spielt offensichtlich eine Rolle beim langsamen Herunterladen von Daten, aber schlecht geschriebener Code oder schlecht gestaltete Technologiepakete (für die Art der Website) spielen eine zunehmend zentrale Rolle beim langsamen Laden dynamischer Inhalte, da die Netzwerkverbindungen schneller sind Annäherung an die Allgegenwart.

Benny
quelle
21
Nein - was Sie beschreiben, kann verhindern, dass Elemente des DOM angezeigt werden, aber nicht nur Text. Die Antwort hat mit dem Ersetzen von Schriftarten zu tun und ist die Schuld der Designer , nicht der Entwickler.
Toby
+1 @Toby, weil es wirklich die Schuld der Designer ist. Es ist auch extrem ärgerlich, wenn Sie sich auf einer langsamen Verbindung befinden (wie zum Beispiel, oh, ich weiß nicht, mein Handy oder das Festnetz zu Hause). Solche Dinge verlangsamen Webseiten und irritieren die Benutzer, ohne dass dies von Vorteil ist.
Magnus
1
Lange Antwort: Entwickler, Entwickler, Entwickler, Entwickler.
Iono
@Toby Die Designer geben an, welche Schriftarten verwendet werden sollen, aber es ist die Aufgabe eines jeden guten Entwicklers, bei der technischen Implementierung die richtigen Entscheidungen zu treffen. Der gute Entwickler würde auch verstehen, warum dies geschieht (siehe Antwort oben), welche Entscheidungen getroffen werden können, um das Problem zu vermeiden (Google Webfont Loader) und wie sich dies auf das Erlebnis auswirkt.
Arbales
3

Kurz gesagt, zu viele ladbare Objekte, die von separaten HTTP-GETs geladen werden müssen, bevor die Seite angezeigt werden kann, und eine zu hohe Abhängigkeit von der durchschnittlichen Latenz als Maß für den Zustand der Site.

Der erste bezieht sich auf alle CSS-, JS- und Webfonts, die auf der Seite geladen werden, ganz zu schweigen von der Tatsache, dass viele Sites auch JSON-Objekte über XHR-Anforderungen abrufen und dann HTML-Code aus diesen mithilfe von Vorlagen generieren müssen.

Aber warum merken sie nicht, dass die Seite langsam ist?

Wahrscheinlich, weil sie irgendwo einen Memecache haben, um die Dinge zu beschleunigen (oder sich nur auf Dateisystem-Caches verlassen) und den Zustand ihrer Site anhand der durchschnittlichen Latenz messen. Somit werden die zwischengespeicherten Objekte mit einer Latenz von 6 Mircrosekunden zurückgegeben und maskieren die Tatsache, dass viele GET-Anforderungen 5000 Millisekunden benötigen, um abgeschlossen zu werden. Durchschnittswerte müssen sterben. Es lebe das Zählen von RTTs über einem akzeptablen Höchstwert! Diese Zahl sollte 0 sein, oder per Definition ist die RTT nicht akzeptabel.

Michael Dillon
quelle
-1

Nun, es gibt mehrere Gründe. Ein Grund ist auch, dass Befehle zum Definieren eines Hintergrunds oder über einer HTML-Seite häufig oder in einem separaten CSS abgerufen werden, das zuerst geladen wird. bevor der Hauptteil des Dokuments geladen wird, der den Text enthält.

Eine andere Ursache ist, dass Webdesigner in den meisten Fällen davon keinen Gebrauch machen, obwohl es möglich ist, die Größe eines Bildes einzugeben. Und so muss der Brouwser zuerst die ganzen Bilder auf die Seiten laden, damit er weiß, wie man Text darum herum schreibt.

Einige Designer, die auch erste Bilder und den nächsten Text anzeigen möchten, erreichen dies durch JavaScript, so dass beispielsweise auf einer einfachen Seite zuerst ein Banner und dann alles andere darauf angezeigt wird.

Aber wenn Sie sich fragen, warum es auf meinen Seiten so viele Spam-Werbematerialien gibt, während ich nur die Nachrichten lesen möchte, dann gibt es eine Lösung für Sie. Sie können Spam-Blocker verwenden, wenn Sie Firefox verwenden. Mit einem solchen Addon kennt der Webbrowser Websites, die Spam bereitstellen, und blockiert sie einfach. Dies führt zu einem viel schnelleren Laden der Seiten, während Sie weiterhin die wichtigen Bilder zu den von Ihnen gelesenen Artikeln sehen können.

Ich würde allen empfehlen, die sich mit langsamen Seitenladevorgängen beschäftigen, um es mit Fidler zu versuchen. fidler kann mit IEexplorer oder mit FireFox (unter Verwendung seiner Proxy-Funktion) verwendet werden. Fidler zeigt Ihnen, wie lange es tatsächlich dauert und wann Teile einer Webseite geladen werden. Es ist ein HTML-Debugging-Tool.

user613326
quelle
Also versuchst du den Leuten zu helfen und runtergestimmt zu werden, ist das nicht lustig? Ok, ich werde es mir noch einmal überlegen, bevor ich die technischen Dinge der Leute hier in Laienbegriffen erkläre.
user613326
21
Sie haben das Falsche erklärt, deshalb werden Sie abgewertet. Wie Sie auf dem Screenshot sehen können, ist die Seite vollständig geladen, nur der Text wird nicht angezeigt. Das hat nichts mit Bildern zu tun.
Femaref
8
Der Hauptteil des Dokuments wird fast immer vor externem CSS geladen. Der Browser hört nicht auf, die Seite zu analysieren, nur um externen Inhalt zu laden. Der Versuch zu helfen ist nur dann nützlich, wenn Sie tatsächlich hilfreich sind. Fehlinformationen sind schlimmer als keine Informationen.
Raylu
1
@raylu Ich weiß nichts über diese Fehlinformation. Manchmal kann es sehr hilfreich sein, eine Antwort mit vielen Abstimmungen zu sehen. :-)
LarsTech
7
Hi @ user613326: Wir empfehlen hier ehrliches Downvoting, da wir in erster Linie hier sind, um der Community nützliche Antworten zu geben. Nimm es nicht persönlich!
Flimm