nicht angemeldet
Matthias Apsel
Christian Kruse
Der Martin
Auge
Friedel
Henry
Henry
Rolf B
Matthias Apsel
Hallo alle,
https://maps.esri.com/rc/sat2/index.html
Wirklich sehenswert.
Bis demnächst
Matthias
Hallo Matthias,
https://maps.esri.com/rc/sat2/index.html
Wirklich sehenswert.
Ja, das finde ich auch. Sehr, sehr cool.
Freundliche Grüße,
Christian Kruse
Hallo,
https://maps.esri.com/rc/sat2/index.html
Wirklich sehenswert.
Ja, das finde ich auch. Sehr, sehr cool.
in der Tat beeindruckend. Ich bin überrascht, dass man die geostationären Satelliten in etwa 36000km Höhe nur als feine Linie erkennt, während erdnahe Satelliten anscheinend viel zahlreicher sind.
Ich hätte es andersrum erwartet.
Live long and pros healthy,
Martin
Hallo
Ich bin überrascht, dass man die geostationären Satelliten in etwa 36000km Höhe nur als feine Linie erkennt, während erdnahe Satelliten anscheinend viel zahlreicher sind.
Naja, da sind halt „nur“ Telekommunikationssatelliten (TV, Komm-Relais etc.). Die sind dann auch jahre- oder gar jahrzentelang im Einsatz und werden nach ihrem Ausscheiden auf einen höheren Friehofsorbit verfrachtet, womit der Platz für den (einen) Ersatzsatelliten frei wird.
In den niedrigeren Orbits (Orbitalen?) tummeln sich zahlenmäßig sehr viel mehr Satelliten für sehr viel mehr Anwendungen der Erdbeobachtung (Wetter, Forschung etc.). Neuerdings ja auch die zahlreichen Internetsatelliten von SpaceX [1], zu denen sich weitere Schwärme von anderen Anbietern gesellen sollen.
Ich hätte es andersrum erwartet.
Ich nicht. 🙂
Tschö, Auge
Es sollen mehrere tausend werden. Mehrere hundert sollten das aber jetzt schon sein. ↩︎
Ja, das ist eine wirklich sehenswerte Site. Nur schade, dass die Doku fehlt. Einige der Bezeichnungen und Abkürzungen sind völlig unklar. Insbesondere wundere ich mich darüber, dass es dort Satelliten auch China gibt und andere Satelliten aus PRC. (Von so einem wurden wir hier gerade überflogen.) Wenn das einen Sinn hat, sollte der irgendwo erklärt werden. Aber trotzdem ist die Site (be-)merkenswert.
Servus!
Ja, das ist eine wirklich sehenswerte Site. Nur schade, dass die Doku fehlt. Einige der Bezeichnungen und Abkürzungen sind völlig unklar. Insbesondere wundere ich mich darüber, dass es dort Satelliten auch China gibt und andere Satelliten aus PRC. (Von so einem wurden wir hier gerade überflogen.) Wenn das einen Sinn hat, sollte der irgendwo erklärt werden.
RoC = Republic of China = Taiwan
PRC = Peoples Republic of China = Volksrepublik
Herzliche Grüße
Matthias Scharwies
RoC = Republic of China = Taiwan
PRC = Peoples Republic of China = Volksrepublik
Das meine ich nicht. Es gibt als Herkunftsland CN und auch PRC. Ich dachte, dass das beides Kürzel für China (Volksrepublik) sind.
Hallo,
RoC = Republic of China = Taiwan
PRC = Peoples Republic of China = Volksrepublik Das meine ich nicht. Es gibt als Herkunftsland CN und auch PRC.
okay, verstanden.
Ich dachte, dass das beides Kürzel für China (Volksrepublik) sind.
Ja. Aber vielleicht von verschiedenen Quellen. Wer China-affin ist, wird vermutlich eher PRC schreiben; wer technik- oder internet-affin ist, wird eher CN bevorzugen.
Live long and pros healthy,
Martin
Hallo Matthias,
Hallo alle,
https://maps.esri.com/rc/sat2/index.html
Wirklich sehenswert.
Absolut, danke für den Link. Besonders, dass man jeden sogar einzeln anklicken/abfragen kann. Schon ne ziemliche Müllhalde dort oben, hätte nichts gegen einen ausreichend starken Sonnensturm.
Gruss
Henry
Hallo,
Wenn ich hier im Forum versuche Threads zu drucken, hier jetzt zb., enthält der Druck, auch wenn alles aufgeklappt ist, nur einen Teil der Postings und auch nicht wirklich schön formatiert. Ist das bekannt und vor allem bei auch auch so, oder betrifft es nur meinen PC?
Gruss
Henry
Hallo Henry,
das scheint ein Firefox Problem zu sein. Der druckt alle Threads auf Seite 2 und beginnt keine neue Seite, wenn es nicht passt.
Mit Chrome geht's besser.
Beiden Browsern ist gemein, dass sie den Footer und die Bilder von AppSignal und Termitel auf eine neue Seite drucken und die beiden Bilder nicht rechts floaten, sondern jedes auf eine eigene Zeile setzen und auf Seitenbreite hochskalieren.
Das Print-Stylesheet scheint suboptimal.
Rolf
Hallo Rolf B,
Das Print-Stylesheet scheint suboptimal.
Es gibt keins (mehr).
Bis demnächst
Matthias
Hallo Matthias,
ja, so kann man es auch sagen 😀
Es scheint aber auch kein Browser-Stylesheet für @media print zu geben. Insofern sollte (page-)break-inside für alle Block-Elemente auf auto stehen.
Ich habe das mal für article und div per Custom CSS zu erzwingen versucht, mit dem Erfolg, dass die Style-Anzeige für article und div im Firefox-Inspector nicht mehr funktionierte. WTF?
Aber auch wenn sie funktioniert - Browser-CSS mit break-* Eigenschaften sehe ich nicht. Dennoch scheint der Firefox die Eigenschaft zu haben, ein article-Element auf einer Seite behalten zu wollen. Weshalb auch immer.
Beim Suchen nach der Ursache habe ich den Tipp gefunden, mit overflow:visible !important; zu arbeiten, aber auch das, angewendet auf article, hatte keinen Effekt.
Etwas Stöbern in den berechneten Browser-Stilen zeigte auch nirgends ein overflow:hidden oder eine auf irgendwas mit vh erzwungene Höhe.
Wie gesagt: in Chrome funktioniert es. Es scheint eine Firefox Macke zu sein. Ich finde im Mozilla Bugzilla einen "unconfirmed" Bug (557281) von 2010, der genau dieses Phänomen beschreibt. WTF?
Es ist aber auch kein Grundsatzproblem; eine Testseite aus header, article und footer mit genug Text im article wird bei mir umgebrochen. Es hat also schon etwas mit dem speziellen HTML/CSS des Forums zu tun.
Rolf
Hallo Matthias,
gefunden, @Christian Kruse
Matthias Scharwiesarticle.cf-thread-nested {
display: inline-block;
}
ist der Auslöser. Deaktiviert man diese Einstellung, ist die Darstellung der nested Ansicht - zumindest auf einem großen Desktop-Fenster - so gut wie unverändert.
Und der Fuchs druckt wieder richtig.
Ich habe eine Support-Frage bei Mozilla gefunden, wo das angesprochen wurde, und da fand sich auch die Antwort, dass Firefox strikter als andere Browser sei was die Umsetzung von Webstandards angehe. Allerdings finde ich keine Spec, die verlangt, dass in eine inline-Box zwangsweise kein page break eingefügt werden darf. Was daran liegen kann, dass die Fragmentierun der Specs auf Einzeldokumente überhand genommen hat - man weiß nicht mehr wo man schauen soll.
Es gibt CSS Fragmentation Module Level 3, da steht unter §3.2, dass die break-inside Eigenschaft für alle Elemente gilt, außer für inline-level Boxen und noch ein paar weiter Ausnahmen. Und in §4.1 steht, dass der Browser eine inline-block Box als monolithisch auffassen kann - aber nicht muss. Monolithisch heißt: Dieses Ding kann nicht fragmentiert werden. D.h. Chrome und Mozilla legen hier eine Kann-Bestimmung unterschiedlich aus. Was ihr Recht ist, aber im Forum zum Abschneiden der Artikel in der Nested-Ansicht führt.
Rolf
Hallo Rolf, hallo Henry,
ich supporte keine Print-Stylesheets. Wenn die Community das wünscht muss das auch aus der Community kommen, sorry. Ist mir zu viel Maintenance-Aufwand.
Freundliche Grüße,
Christian Kruse
Hallo Christian,
einverstanden. Brauchen wir auch nicht, wenn es nur das
.cf-thread-nested {
display: inline-block;
}
ist. Ist diese Eigenschaft zwingend erforderlich? Ich habe sie einfach mal abgeschaltet und die Darstellung schien weiterhin okay, aber ich habe auch nicht alle Viewportgrößen durchprobiert. Ich habe in mein Custom-CSS ein display:block !important; für diese Klasse eingesetzt und beobachte das jetzt mal.
Kannst Du ja auch machen, Henry, und gucken wie es sich damit druckt.
Rolf
Hallo Rolf B,
einverstanden. Brauchen wir auch nicht, wenn es nur das
.cf-thread-nested { display: inline-block; }ist. Ist diese Eigenschaft zwingend erforderlich?
Ich würde sagen ja, und zwar wenn die Einrückung der Beiträge größer wird als die Breite der Einzelbeiträge.
Bis demnächst
Matthias
Hallo Matthias,
kann ich nicht nachvollziehen; vielleicht habe ich keinen hinreichend weit eingerückten Thread dafür gefunden.
Hast Du ein Beispiel wo es zu Darstellungsfehlern führt?
Was man übrigens nicht tun sollte, ist ein break-inside: avoid für die Klasse posting-nested. Das hat mir Chrome in eine Endlosschleife geschickt.
Rolf
Hallo Rolf,
bei diesem Thread kannst du das z.B. sehen. Die Postings wachsen in der Breite.
Freundliche Grüße,
Christian Kruse
Hallo Matthias,
.cf-thread-nested { display: inline-block; }ist. Ist diese Eigenschaft zwingend erforderlich?
Ich würde sagen ja, und zwar wenn die Einrückung der Beiträge größer wird als die Breite der Einzelbeiträge.
Exakt. Sonst wachsen bei langen Threads die einzelnen Beiträge über die max-width hinaus.
Freundliche Grüße,
Christian Kruse
Hallo Christian Kruse,
Exakt. Sonst wachsen bei langen Threads die einzelnen Beiträge über die
max-widthhinaus.
Und wenn ich mich recht erinnere, rutscht auch die zweite Antwort auf das OP an eine falsche Stelle, wenn der Ast der ersten Antwort auf das OP zu breit wird. Also so
____
____
____
____
____
____
____
____
THIS
THIS rutscht dann nach oben.
Bis demnächst
Matthias
Hallo Christian und Matthias,
ich weiß echt nicht, wovon ihr redet. Ich kann nichts feststellen. Mit Chrome und Firefox bleibt die Darstellung unverändert, wenn ich
.cf-thread-nested {
display: block !important;
}
im User-CSS aktiviere (oder alternativ die mitgelieferte Regel deaktviere). Wenn ich dann per Developer-Tools die Eigenschaft hin- und herschalte, passiert nur eines: Wenn die Oberkante des ersten Postings über dem oberen Fensterrand ist, verschiebt sich die Darstellung um ca 1em nach oben (oder unten?). Aber die Darstellung an sich verändert sich nicht, alle Breiten bleiben unverändert.
Gilt das Problem nur für bestimmte Display- oder Viewportgrößen? Oder nur für bestimmte Devices? Die Toggelei ist mir auf dem Smartphone jetzt zu mühsam.
Rolf
Hallo Rolf,
Wenn ich dann per Developer-Tools die Eigenschaft hin- und herschalte, passiert nur eines: Wenn die Oberkante des ersten Postings über dem oberen Fensterrand ist, verschiebt sich die Darstellung um ca 1em nach oben (oder unten?).
Ja. Aber das ist nur ein Symptom. Die Ursache ist die Veränderung der Breite einiger Postings.
Gilt das Problem nur für bestimmte Display- oder Viewportgrößen?
Nein. Aber ggfls. wir das Problem bei tiefer verschachtelten besser sichtbar. Hab nur gerade keinen zur Hand 😀
Freundliche Grüße,
Christian Kruse
Hallo Christian Kruse,
ich hab jetzt ein bisschen gesucht und getrickst.
Ich meine für eine solche Situation war das relevant. Aber ich kann es nicht mehr nachstellen. Und wir hatten auch mal das Problem, dass weit eingerückte Links im Threadbaum abgeschnitten wurden. Aber vielleicht ist das auch nur noch ein Relikt und mit dem Umbau auf flex hinfällig geworden.
Bis demnächst
Matthias