MSIE 11 ein paar Beobachtungen
beatovich
- browser
- css
- javascript
hallo
ich habe folgende Beobachtungen beim MSIE 11 gemacht
_.xhr = new XMLHttpRequest();
_.xhr.responseType = 'document'; // ERROR
_.xhr.open("GET",_.sitemapUri);
Korrektur
_.xhr = new XMLHttpRequest();
_.xhr.open("GET",_.sitemapUri);
_.xhr.responseType = 'document'; // Jetzt korrekt
Die Reihenfolge machts aus
MSIE braucht die Encoding Angabe als Response header. html charset Angaben werden nicht geparst!
AddCharset UTF-8 .html
MSIE kennt Element.remove()
Nicht aber wenn das Element ein noscript-Element ist! Also über node entfernen
function removeNoscript(b,r){
r=b.querySelector("noscript");
if(r) r.parentNode.removeChild(r);
return b;
}
main {
flex: 2 0 auto;
width:100%; /* auch wenn FF ohne auskommt, MSIE braucht es zur Zentrierung*/
max-width:55em;
margin:0 auto; padding: 1vh 1em 5vh;
Wer's glaubt oder nicht.
.nav_main > div dl{
display:flex;
display:grid;
grid-column-gap: 1em;
grid-template-columns: repeat(4, auto minmax(8em , auto));
justify-content: center;
}
flex führt zu einer fast identischen Darstellung in diesem Fall.
Ich bin sicher, einige der Punkte betreffen mehr meine Blödheit als MSIE.
Tach!
xhr und UTF-8
MSIE braucht die Encoding Angabe als Response header. html charset Angaben werden nicht geparst!
Nicht nachvollziehbar. Arbeitet korrekt nach Vorschrift. Das wäre auch ein zu großer Fehler, der alle möglichen Sites kaputtmachen würde, als dass man den einfach unberücksichtigt lassen würde.
Angaben im Dokument werden generell nur berücksichtigt, wenn eine charset-Angabe im Content-Type-Header fehlt.
AddCharset UTF-8 .html
Zudem gibt es eine Menge Server, die nicht mit Apache-Direktiven konfigurierbar sind. Für solche Beobachtungen sollte man schauen, was im HTTP übertragen wird (und in dem Fall in Kombination mit dem HTML), statt was am Server zu konfigurieren ist.
dedlfix.
hallo
Tach!
xhr und UTF-8
MSIE braucht die Encoding Angabe als Response header. html charset Angaben werden nicht geparst!
Nicht nachvollziehbar. Arbeitet korrekt nach Vorschrift. Das wäre auch ein zu großer Fehler, der alle möglichen Sites kaputtmachen würde, als dass man den einfach unberücksichtigt lassen würde.
Angaben im Dokument werden generell nur berücksichtigt, wenn eine charset-Angabe im Content-Type-Header fehlt.
AddCharset UTF-8 .html
Zudem gibt es eine Menge Server, die nicht mit Apache-Direktiven konfigurierbar sind. Für solche Beobachtungen sollte man schauen, was im HTTP übertragen wird (und in dem Fall in Kombination mit dem HTML), statt was am Server zu konfigurieren ist.
Muss ich ein Video auf Youtube hochladen um es dir zu beweisen? Erspare mir das bitte und glaube, dass es nachvollziehbar so existiert.
Tach!
Muss ich ein Video auf Youtube hochladen um es dir zu beweisen? Erspare mir das bitte und glaube, dass es nachvollziehbar so existiert.
Der Glaube an eine Nachvollziehbarkeit hilft nicht weiter, besonders dann nicht, wenn ich sehen kann, dass es nicht so ist, wie von dir beschrieben. Eine Auflistung der Resonse-Header und der relevanten Meta-Elemente reicht aber auch. Video muss nicht sein.
dedlfix.
hallo
Tach!
Muss ich ein Video auf Youtube hochladen um es dir zu beweisen? Erspare mir das bitte und glaube, dass es nachvollziehbar so existiert.
Der Glaube an eine Nachvollziehbarkeit hilft nicht weiter, besonders dann nicht, wenn ich sehen kann, dass es nicht so ist, wie von dir beschrieben. Eine Auflistung der Resonse-Header und der relevanten Meta-Elemente reicht aber auch. Video muss nicht sein.
dedlfix.
Header:
Accept-Ranges
bytes
Connection
Keep-Alive
Content-Length
3432
Content-Type
text/html
Date
Mon, 20 Aug 2018 06:20:26 GMT
ETag
"11d0000000536a0-d68-573d3c41576ff"
Keep-Alive
timeout=5, max=100
Last-Modified
Mon, 20 Aug 2018 01:24:08 GMT
Server
Apache/2.2.25 (Win32)
html Meta Angaben
<meta charset="utf-8">
<meta name="description" lang="de" content="Sitemap">
<meta name="date" content="2018-07-01">
<meta name="last-modified" content="2018-08-01">
Diese existieren im Haupt-Dokument wie auch in der Sitemap, die über xhr eingebaut wird. Die Header werden zudem durch ein Script noch vor dem xhr-Request durch weitere Meta Angaben ergänzt, was vielleicht die Seltenheit des Phänomens begründen kann.
Tach!
Header:
Content-Type text/html
html Meta Angaben
<meta charset="utf-8">
Damit und beschränkt darauf funktioniert es einwandfrei.
Diese existieren im Haupt-Dokument wie auch in der Sitemap, die über xhr eingebaut wird. Die Header werden zudem durch ein Script noch vor dem xhr-Request durch weitere Meta Angaben ergänzt, was vielleicht die Seltenheit des Phänomens begründen kann.
Du hast da also eine spezielle Situation vorliegen, die man nicht verallgemeinern kann. Wenn eine der Responses keine charset/encoding-Angabe mitschickt, dann kann das durchaus zu Fehlern führen, die auf dem einen oder anderen System nicht zu bemerken sind, weil die eine andere Fehlerkorrektur oder Default-Einstellung haben.
dedlfix.
hallo
Tach!
Header:
Content-Type text/html
html Meta Angaben
<meta charset="utf-8">
Damit und beschränkt darauf funktioniert es einwandfrei.
Diese existieren im Haupt-Dokument wie auch in der Sitemap, die über xhr eingebaut wird. Die Header werden zudem durch ein Script noch vor dem xhr-Request durch weitere Meta Angaben ergänzt, was vielleicht die Seltenheit des Phänomens begründen kann.
Du hast da also eine spezielle Situation vorliegen, die man nicht verallgemeinern kann. Wenn eine der Responses keine charset/encoding-Angabe mitschickt, dann kann das durchaus zu Fehlern führen, die auf dem einen oder anderen System nicht zu bemerken sind, weil die eine andere Fehlerkorrektur oder Default-Einstellung haben.
Deine Beschreibung trifft meine Situation nicht. ALLE html-Dateien bringen ihre charset Angabe im html head mit! Und zwar die gleiche. Sitemap.html ist eine normale html-Datei.
Muss ich ein Video auf Youtube hochladen um es dir zu beweisen?
Wie wäre es mit einem Online-Beispiel?
hallo
Muss ich ein Video auf Youtube hochladen um es dir zu beweisen?
Wie wäre es mit einem Online-Beispiel?
Ich will euch nicht überzeugen. Ich beobachte.
Bisher unbesprochen blieb, dass ich Dokumente als UTF-8 ohne BOM speichere.
hallo
ich habe folgende Beobachtungen beim MSIE 11 gemacht
xhr.responseType
_.xhr = new XMLHttpRequest(); _.xhr.responseType = 'document'; // ERROR _.xhr.open("GET",_.sitemapUri);
Korrektur
_.xhr = new XMLHttpRequest(); _.xhr.open("GET",_.sitemapUri); _.xhr.responseType = 'document'; // Jetzt korrekt
Die Reihenfolge machts aus
War schon immer so. Auch in FF.
MfG
hallo
hallo
ich habe folgende Beobachtungen beim MSIE 11 gemacht
xhr.responseType
_.xhr = new XMLHttpRequest(); _.xhr.responseType = 'document'; // ERROR _.xhr.open("GET",_.sitemapUri);
Korrektur
_.xhr = new XMLHttpRequest(); _.xhr.open("GET",_.sitemapUri); _.xhr.responseType = 'document'; // Jetzt korrekt
Die Reihenfolge machts aus
War schon immer so. Auch in FF.
FF meckert nicht in der ersten Version. Vielleicht hat er sich das auch abgewöhnt.
hallo
FF meckert nicht in der ersten Version. Vielleicht hat er sich das auch abgewöhnt.
Allgemein: xhr.open() aufrufen bevor weitere Methoden aufgerufen oder Eigenschaften gesetzt werden.
MfG
@@beatovich
main { flex: 2 0 auto; width:100%; /* auch wenn FF ohne auskommt, MSIE braucht es zur Zentrierung*/
Das dürfte daran liegen, dass IE das main
-Element nicht kennt, d.h. nicht main { display: block }
in seinem Browserstylesheet zu stehen hat.
Das sollte man ins Stylesheet schreiben, für Fälle, wo main
kein Flexitem ist. Eine width
-Angabe sollte nicht nötig sein.
LLAP 🖖
hallo
@@beatovich
main { flex: 2 0 auto; width:100%; /* auch wenn FF ohne auskommt, MSIE braucht es zur Zentrierung*/
Das dürfte daran liegen, dass IE das
main
-Element nicht kennt, d.h. nichtmain { display: block }
in seinem Browserstylesheet zu stehen hat.Das sollte man ins Stylesheet schreiben, für Fälle, wo
main
kein Flexitem ist. Einewidth
-Angabe sollte nicht nötig sein.
Will ich dir mal so glauben, da ich da keine besonderen Tests gemacht habe.
Danke
Hallo beatovich,
main { flex: 2 0 auto; width:100%; /* auch wenn FF ohne auskommt, MSIE braucht es zur Zentrierung*/
IE braucht keine 100% wegen der Zentrierung, sondern schlicht weil er <main> nicht kennt und somit als Inlineelement behandelt, lässt sich aber korrigieren mir display:block;
Gruss
Henry
@@Henry
IE braucht keine 100% wegen der Zentrierung, sondern schlicht weil er <main> nicht kennt und somit als Inlineelement behandelt, lässt sich aber korrigieren mir display:block;
Erster! 😜
LLAP 🖖
hallo
@@Henry
IE braucht keine 100% wegen der Zentrierung, sondern schlicht weil er <main> nicht kennt und somit als Inlineelement behandelt, lässt sich aber korrigieren mir display:block;
Erster! 😜
LLAP 🖖
doppelt gemoppelt könnt ihr mir das Blaue vom Himmel versprechen.
hallo
hallo
@@Henry
IE braucht keine 100% wegen der Zentrierung, sondern schlicht weil er <main> nicht kennt und somit als Inlineelement behandelt, lässt sich aber korrigieren mir display:block;
Erster! 😜
LLAP 🖖
doppelt gemoppelt könnt ihr mir das Blaue vom Himmel versprechen.
Genau, die width Angabe ist nämlich trotzdem notwendig!
@@beatovich
Genau, die width Angabe ist nämlich trotzdem notwendig!
In welchem Fall sollte das der Fall sein?
LLAP 🖖
hallo
@@beatovich
Genau, die width Angabe ist nämlich trotzdem notwendig!
In welchem Fall sollte das der Fall sein?
Im Fall des geposteten CSS: main als flex-item
@@beatovich
Im Fall des geposteten CSS: main als flex-item
So schlau war ich auch.
Wie sieht die Flexbox aus? Link zur Testseite?
LLAP 🖖
hallo
@@beatovich
Im Fall des geposteten CSS: main als flex-item
So schlau war ich auch.
Wie sieht die Flexbox aus? Link zur Testseite?
Hallo Gunnar,
Erster! 😜
Yepp, Anruf kam während meiner Antwort rein 😉
Gruss
Henry
r=b.querySelector("noscript"); if(r) r.parentNode.removeChild(r);
Zu welch besonderen Behufe sollte ich - mit Javascript - ein Element manipulieren (hier: entfernen), welches per Definition vom Browser ignoriert, jedenfalls nicht angezeigt wird, wenn Javascript verfügbar und aktiviert ist?