Microsoft verbetert siteweergave IE op Windows Phone

Microsoft heeft de weergave van sites in Internet Explorer 11 op Windows Phone 8.1 verbeterd door enkele ingrepen. Voor de verbeterde weergave hebben gebruikers wel de nog niet uitgebrachte Windows Phone 8.1 Update nodig.

Microsoft geeft de browser bij het bezoeken van sites een nieuwe user agent mee, omdat veel sites de Windows Phone-browser zien als desktopbrowser en dus een andere layout meegeven. Door de user agent te wijzigen, vermoedelijk door iets als 'Like Gecko' toe te voegen, schotelen de websites gebruikers wel de juiste layout voor. Welke wijziging Microsoft aanbrengt, zegt het bedrijf niet. Het zien van de juiste mobiele layout is gebruiksvriendelijker en bespaart data, zegt Microsoft.

Daarnaast gaat ondersteuning voor enkele Webkit-specifieke features toevoegen. IE11 heeft Trident als layout-engine, maar browsers als Safari op iOS en de naamloze standaardbrowser en Chrome op Android gebruiken Webkit. Als een site nu Webkit-specifieke features heeft, probeert IE11 als de pagina laadt die code om te zetten in code waar IE11 wel mee om kan gaan. Ook zijn er enkele css-issues opgelost.

Ook zijn er problemen waar Microsoft nog steeds mee zit. Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles.

De nieuwe versie van IE11 voor Windows Phone komt beschikbaar bij de update voor 8.1. Microsoft verspreidt die volgende week over-the-air onder ontwikkelaars via de Developer Preview-app. Ook gebruikers die niet de Nokia Cyan-update op hun Lumia hebben gekregen, omdat ze de Developer Preview draaien, krijgen alsnog 8.1 Update binnen.

Reacties (79)

[ultimasnake]

Ik krijg de kriebels van ongeveer alles na de 2de alinea..

Door de user agent te wijzigen, vermoedelijk door iets als 'Like Gecko' toe te voegen,.......... Welke wijziging Microsoft aanbrengt, zet het bedrijf niet. Het zien van de juiste mobiele layout is gebruiksvriendelijker en bespaart data, .........
- Dus developers kunnen er niet op anticiperen tot de eerste bezoekers met IE11 op 8.1 langs komen en een andere user agent zien?

Als een site nu Webkit-specifieke features heeft, probeert IE11 als de pagina laadt die code om te zetten in code waar IE11 wel mee om kan gaan. Ook zijn er enkele css-issues opgelost.
- Haar gaat overeind staan door alleen al de ellende die 'Compatibility-view' tot heden met zich mee brengt..... Interpretatie van, conversie naar kan nooit goed gaan.... En wat zijn die webkit features dan? --webkit-(css3spec hier) kan ik alleen zo snel bedenken... Maar dat gaat vaak gewoon gepaard met de css3 tag zodat deze ook opgepakt kan worden (wat uiteindelijk de browser specifieke rules overbodig moet maken bij support)


Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles.
- Er kan dus geen onderscheid gemaakt worden door MS zelf op hun OS+Browser tussen een muis of een vinger? (iaw een beetje zoals de goedkope touchscreen in kiosken waar je vinger letterlijk de muis na bootst?)

[RayNbow]

Door de user agent te wijzigen, vermoedelijk door iets als 'Like Gecko' toe te voegen,.......... Welke wijziging Microsoft aanbrengt, zet het bedrijf niet. Het zien van de juiste mobiele layout is gebruiksvriendelijker en bespaart data, .........
- Dus developers kunnen er niet op anticiperen tot de eerste bezoekers met IE11 op 8.1 langs komen en een andere user agent zien?

Je moet dan ook niet naar de user agent kijken, maar altijd testen op features. Dit wordt ook vermeld in het bronartikel door Microsoft zelf. Als je per se de user agent string wilt gebruiken om voor een mobiel geoptimaliseerde ervaring te leveren, dan raadt Microsoft aan om alleen te kijken of de string "mobile" voorkomt in de naam van de user agent.

Als een site nu Webkit-specifieke features heeft, probeert IE11 als de pagina laadt die code om te zetten in code waar IE11 wel mee om kan gaan. Ook zijn er enkele css-issues opgelost.
- Haar gaat overeind staan door alleen al de ellende die 'Compatibility-view' tot heden met zich mee brengt..... Interpretatie van, conversie naar kan nooit goed gaan.... En wat zijn die webkit features dan? --webkit-(css3spec hier) kan ik alleen zo snel bedenken... Maar dat gaat vaak gewoon gepaard met de css3 tag zodat deze ook opgepakt kan worden (wat uiteindelijk de browser specifieke rules overbodig moet maken bij support)

Het probleem hier is dat blijkbaar veel sites alleen de webkit-prefix opnemen in hun CSS en niet de W3C standaard. In de update van IE11 worden bepaalde webkit-features gemapt op de W3C standaard.

Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles.
- Er kan dus geen onderscheid gemaakt worden door MS zelf op hun OS+Browser tussen een muis of een vinger? (iaw een beetje zoals de goedkope touchscreen in kiosken waar je vinger letterlijk de muis na bootst?)

Windows kan al heel goed het onderscheid maken tussen muis, toetsenbord, pen en touch. Het probleem ligt hem in de Touch Events API. Als ik een webpage maak waarin ik alleen de Touch Events API gebruik, hoe moet IE met mijn pagina omgaan? Als een bezoeker een pen gebruikt, moet IE er dan voor zorgen dat mijn pagina op pen-events reageert? Als een bezoeker een muis gebruikt, moet IE er dan voor zorgen dat de muis een vinger nabootst?

Microsofts voorstel (Pointer Events) is een modernere en een stuk logischere API. Deze API stelt de webdeveloper in staat om touch/muis/pen uniform hetzelfde te behandelen, of wanneer nodig is, expliciet aan te geven dat ze apart moeten worden afgehandeld.

[PolarBear]

- Dus developers kunnen er niet op anticiperen tot de eerste bezoekers met IE11 op 8.1 langs komen en een andere user agent zien?

Developers die doormiddel van user agents anticiperen op bezoekers, ik kan mij niet echt een goede use case voorstellen. Volgens mij is verschillende content serveren op basis van user agent niet echt een good practise.

- Haar gaat overeind staan door alleen al de ellende die 'Compatibility-view' tot heden met zich mee brengt..... Interpretatie van, conversie naar kan nooit goed gaan.... En wat zijn die webkit features dan? --webkit-(css3spec hier) kan ik alleen zo snel bedenken... Maar dat gaat vaak gewoon gepaard met de css3 tag zodat deze ook opgepakt kan worden (wat uiteindelijk de browser specifieke rules overbodig moet maken bij support)

Compatibility view heeft alleen te maken met oudere IE versies nabootsen. Webkit ontwikkeld/gebruikt dingen die nog niet geheel zijn gestandaardiseerd zijn. Zie bijvoorbeeld dit bericht http://developers.slashdo...bkit-breaks-web-standards. Het voornaamste probleem is dat de veel (mobile) webdevelopers de -webkit features gebruiken en geen alternatieven implementeren. Zie http://www.sitepoint.com/w3c-css-webkit-prefix-crisis/

It works well in theory but consider what happens in the wild:

Experimental properties are often implemented in the webkit engine first and there’s no guarantee they’ll be replicated in other browsers.
It’s often difficult to determine whether a vendor-prefixed property is part of the CSS specification. Some vendors don’t submit properties for standardization.
Even if the standard property changes, the incorrect vendor-prefixed version continues to be supported. Your old code still works; you won’t revisit it to correct the implementation.

- Er kan dus geen onderscheid gemaakt worden door MS zelf op hun OS+Browser tussen een muis of een vinger? (iaw een beetje zoals de goedkope touchscreen in kiosken waar je vinger letterlijk de muis na bootst?)

Microsoft gebruik voor zo ver ik weet Pointer Events die prima werken en onderscheid kunnen maken tussen de verschillende input apparaten.

[ultimasnake]

@RayNbow en @PolarBear,

Inderdaad is op UserAgent niet de meest waterdichte wijze maar het wordt toch heel veel gebruikt en dat is dan ook te zien aan sites die nu slecht anticiperen op windows phones en het feit dat Microsoft hier via de User Agent string de oplossing wilt bieden. Het ging mij echter vooral om het feit 'we doen iets om het probleem op te lossen met de string maar vetellen me niet wat'

Het tweede punt is valide maar ook hier doelde ik dus aan de intepretaties die MS al vaker deed in browsers, want het is leuk die compatiblity-modus maar het maakt vaak meer stuk. Het is om verrote 'hack' sites te fixen in een wat minder belabberde browser maar maakte ook goede compatible code stuk indien de dev niet afdwong dat het niet nodig was.

En schijnbaar kan Windows dit prima zelf, maar waarom IE11 niet? Touch events zijn meer dan prima te onderscheiden op browsers op IOS en Android met simpele event handlers maar waarom verzuimt de browser in dit geval het verschil aan de man te brengen? Vooral gezien Microsoft heilig gelooft (geloofde) in het samensmelten van tablet/pc...

[RayNbow]

En schijnbaar kan Windows dit prima zelf, maar waarom IE11 niet?

Windows en IE11 kunnen het wel, ...

Touch events

...maar Touch Events is een API die zich louter focust op touch. De grote vraag is dus wat je moet doen met een website die alleen gebruikmaakt van de oude Touch Events API en niet op een iPhone/etc. wordt geladen.

Ter illustratie citeer ik het volgende uit het bronartikel:

for example, we found that mouse and trackpad support is broken on about 10% of top sites when Touch Events are enabled. Many sites don't expect to be able to receive touch events and mouse events and only support one or the other.

zijn meer dan prima te onderscheiden op browsers op IOS en Android met simpele event handlers

Iets als een iPad kan alleen touch herkennen. Je kunt er geen muis of Wacom tablet op aansluiten?

maar waarom verzuimt de browser in dit geval het verschil aan de man te brengen? Vooral gezien Microsoft heilig gelooft (geloofde) in het samensmelten van tablet/pc...

Het probleem is simpelweg het ondersteunen van een oude API dat zich alleen richt op touch in een omgeving wat meerdere soorten invoerapparaten kent. IE11 maakt wel zeker onderscheid in de verschillende invoerapparaten, maar een website moet dan wel de nieuwe Pointer Events API gebruiken.

Een ander voorbeeld om aan te tonen dat het vertalen van nieuwe invoersignalen naar iets wat oude software snapt niet altijd triviaal is: Touch-invoer voor DOS games die een muis rechtstreeks aanspreken als een relatief invoerapparaat.

[Verwijderd]

Touch event is verouderd en kan ook nooit een definitieve W3C standaar worden omdat Apple hun patenten er niet voor vrij wil geven.
Effectief zou daarom veel beter pointer events gebruikt moeten worden.

Maar er zijn flink wat voor iphone gebouwde sites die touch event zijn blijven gebruiken.

[Martinspire]

Klopt helemaal. De alinea klopt dan ook niet. MS ondersteund geen touch-events, waardoor veel sites met gestures de mist in gaan. Nu zullen ze waarschijnlijk toch een (beperkte) variant invoeren om in ieder geval de support terug te krijgen.

Uiteindelijk moeten het ook pointer-events worden, aldus de W3C standaard. De vraag is echter hoeveel sites dat nog gaan aanpassen de komende paar jaar.

[Reactie gewijzigd door Martinspire op 22 juli 2024 23:19]

[Verwijderd]

Microsoft ondersteunt wel pointer events want het is een door Microsoft voorgestelde standaard

[Martinspire]

Ja sorry, haalde ze door elkaar

[TheCoon]

Hmm, ik hoop dat ik dan Tweakers een beetje fatsoenlijk kan bezoeken. Want nu knalt ie er halverwege een artikel uit. Mag blij zijn als ik dit bericht kan afmaken.

[RayNbow]

Als je de eerder aangehaalde [bug] Site performance op Windows Phone 8.1 naslaat kun je een custom CSS fix vinden. Om custom CSS te kunnen instellen in je voorkeuren moet je wel de feature aanschaffen via de karmastore.

[Reactie gewijzigd door RayNbow op 22 juli 2024 23:19]

[ndonkersloot]

Werkt als een trein! Bedankt .

[biglia]

Hopelijk voordat de Android app helemaal verdwijnt, en dat is blijkbaar niet lang meer.

[hcd320]

2005 browser hell all over again ???

Hopelijks wordt 't snel allemaal gefixd want WebDev is geen pretje door al deze verschillende standaarden. Wel goed dat MS nu ook even naar anderen kijkt ipv altijd hun eigen standaard te willen doorduwen...

[raymens]

Het is nu juist andersom zoals ik het begrijp, de andere zitten hun eigen standaarden en prefixen door te duwen en Microsoft moet maar volgen

[Verwijderd]

Niet hun eigen standaarden, maar implementaties van W3C standaarden die nog niet definitief zijn.

De W3C geeft standaarden op een bepaald moment vrij voor implementatie, om zo input uit het veld te krijgen van hoe het in de praktijk werkt. Deze zie je in css terug met de browser specifieke prefixes.

De hel rond het millennium was volgens mij dat Microsoft geheel eigen dingen verzon in IE6 die aan geen enkele standaard commissie werden voorgelegd en waarvan je de werking proefondervindelijk moest vaststellen. En natuurlijk het fout implementeren van css die al gestandaardiseerd was.

Zo erg als toen zal het hoop ik niet meer worden. Je wordt hooguit gek van alle prefixes, maar dat krijg je als je css wil gebruiken die nog niet gestandaardiseerd is.

[Armin]

maar implementaties van W3C standaarden die nog niet definitief zijn.

... en vaak/soms ook niet worden.

[Loller1]

... of nog zo veranderd worden dat de huidige implementatie foutief is.

[Verwijderd]

Daarom worden ze vrijgegeven. Je kan 100 jaar droog testen, maar pas bij implementatie weet je daadwerkelijk of het werkt.

[Verwijderd]

Als blijkt uit de implementaties dat het niet werkt, dan klopt dat ja.

[Loller1]

Uhm nee, het gaat wel degelijk ook over Webkit specifieke features, zoals " sticky".

[Verwijderd]

Je bedoelt dit voorstel binnen W3C?

http://lists.w3.org/Archi...w-style/2012Jun/0627.html

http://dev.w3.org/csswg/css-position/#position

Dus nee, dit is geen verzinsel van Webkit zelf, maar komt ook gewoon van de standaard commissie.

[Loller1]

Het IS een Webkit verzinsel, dit is trouwens de eigenlijke draft die browsers horen te implementeren: http://www.w3.org/TR/css3-positioning/. Waar jij naar verwijst, is alles, behalve standaard.

[Verwijderd]

Ik zeg helemaal niet dat het standaard is. Ik zeg alleen dat het geen webkit verzinsel is, maar dat het gewoon netjes binnen W3C besproken en beschreven staat.

[Loller1]

Nadat het in Webkit werd geïmplementeerd. Is wel degelijk iets dat Webkit verzonnen heeft.

[Verwijderd]

Dus als Webkit iets iets van de W3C als eerste implementeert, mag het wat jouw betreft nooit standaard worden? Begrijp ik het nu goed?

Als Webkit het had geïntroduceerd zonder inbreng van W3C, dan had je het een Webkit verzinsel kunnen noemen. Dat is niet zo, dus je klacht is niet meer dan klets.

Sowieso... De originele vraag om postion:sticky stamt al uit 2002. En ook Mozilla ondersteund het in Gecko. Microsoft heeft het (zoals altijd) in overweging. Het is al jaren experimenteel. Ontwikkelaars zitten er met smart op te wachten. Maar jij komt niet verder dan dat het geen officiële standaard is.

Met die houding zou het internet nog platte text geweest zijn.

*Edit: Ik deed de domme aanname dat position:sticky door Webkit voorgesteld zou kunnen zijn, omdat Loller1 zich er zo druk over maakte. Maar zelfs dat is niet het geval. Webkit is toevallig de eerste die het ondersteund.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[X-Fighter]

Het is dus volledig andersom... Het ligt aan de slechte programmeurs van websites, niet aan Microsoft.

[hackerhater]

Inderdaad in dit geval.
Als mensen nog niet final spul gebruiken moeten ze alle prefixen vermelden.
Zo doe ik dat ook.

[Armin]

Vroeger testen mensen enkel op IE6, nu zie je sommige webdevelopers enkel testen op Chrome, iOS en de twee Androids die ze zelf toevallig hebben.

[johnkeates]

Ik moet hier wel een beetje om gniffelen. Microsoft die browser-specifieke opties gaat implementeren uit andere browsers. Omgekeerde wereld!

[Verwijderd]

Resultaat is nog altijd mager.

Op het mobiele platform worden in de html5test.
Slechts 372/550 punten gehaald met wp8.1, wel 40 meer dan de vorige IE, maar BBos10 en chrome browser halen scores van 491 en 490 uit de 550 voor die test.

Daarbij kan wel gezegd worden, dat de html5test, ook kenmerken test die nog niet gestandaardiseerd zijn in de html5 normen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[halofreak1990]

Daarbij kan wel gezegd worden, dat de html5test, ook kenmerken test die nog niet gestandaardiseerd zijn in de html5 normen.

Ja, en daarom vindt ik veel van dat soort tests bullshit en neem ze dan ook niet serieus. IE houdt zich aan de officiële standaarden, en implementeert nauwelijks de experimentele 'features' die de andere browsers wel hebben. Om een browser daarop af te rekenen is niet eerlijk.

[Armin]

Om een browser daarop af te rekenen is niet eerlijk

Plus als je als website bouwer die features gebruikt sluit je ook meteen alle oude browsers van allerlei merken uit.

[HMC]

Het is toch wel vrij algemeen bekend dat MS met IE een van de lateren waren om eens op een meer schappelijke manier met W3C (die toch wel als de standaard geldt) om te gaan.

[Martinspire]

Nee, ze zijn niet te snel met het implementeren. Want zo is bijvoorbeeld het Box-model vervangen door het Flex-model en die wordt juist weer op oudere Androids niet ondersteund.

[Verwijderd]

Ja, en daarom vindt ik veel van dat soort tests bullshit en neem ze dan ook niet serieus.

Bullshit?
Er worden functies getest, die functies bestaan, en het is heel simpel, als je die als webbeheerder gebruikt op je pagina, en een browser ondersteund diezelfde mogelijkheid kun je een pagina mogelijk sneller, stabieler, mooier, met minder data, of met minder systeem belasting laden.

Zolang zoiets bestaat, de web-bouwer het gebruikt, en jouw browser dat begrijpt, is het geen bullshit, maar zorgt het voor een betere web-ervaring.

Dus ook functies die nog niet zijn bestempeld als standaard, kun je zolang de webbouwer en browser dezelfde taal spreken daar voordeel uithalen.

Hetzelfde goldt ook voor de wifi-ac apparatuur voor jan 2014. Die waren en zijn een stuk sneller dan wifi-n apparatuur. Wat voor jou als gebruiker weldegelijk nut heeft en had al was de standaard nog niet vastgesteld door de IEEE.

Dus stellen dat de html5test bullshit test is onzin. Het zijn bestaande html5 functies, die je browser wel, of niet begrijpt. Begrijpt je browser meer van die functies, dan kan hij meer, en werkt hij bij gebruik van die functies ook mogelijk efficiënter.

[Verwijderd]

en implementeert nauwelijks de experimentele 'features' die de andere browsers wel hebben.

De W3C roept browsermakers op om mee te werken aan de ontwikkeling van standaards, maar Microsoft heeft daar geen behoefte aan.

Dat heeft wel als nadeel dat de anderen alleen nog hoeven te schaven aan hun implementatie als de standaard definitief wordt, terwijl Microsoft dan pas kan starten met ontwikkelen. De geschiedenis leert dat Microsoft standaard laat komt met nieuwe html/css standaards dus je aanname dat ze het op de plank hebben liggen lijkt me wishfull thinking.

Die tests zijn mede om te controleren hoe de browsers omgaan met de nieuwe features, daar alleen uitgekauwde features testen zou de test totaal overbodig maken lijkt mij.

Maar volgens mij komt Microsoft daar nu al op terug. Ik heb de indruk dat ook zij wel beginnen met het implementeren van niet uitontwikkelde features. Het zijn vooral de devvers die daar nog aan moeten wennen heb ik het idee.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[Martinspire]

JUIST omdat ze niet final zijn, zou het niet zo zwaar moeten wegen of duidelijk moeten zijn dat een deel van de score is gebaseerd op standaarden die nog niet af zijn.
Het is gewoon foute informatie

[Verwijderd]

Dan is die test gewoon verkeerd. Ik ben al wezen zoeken maar ik kan geen HTML5 test vinden die zeg maar checkt op de final (gestandaardiseerde) spec. Iemand?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[BM]

Dat kun jij hieruit afleiden? Wie zegt dat Microsoft die features niet al op de plank heeft liggen voor als het wél een standaard word?

Daarbij, een standaard die niet final is is dus géén standaard, om software af te rekenen op het feit dat die nog niet ondersteund zijn is wel erg makkelijk.

[Verwijderd]

Omdat ze o.a. bij Web Components zeggen: We nemen het in overweging terwijl FireFox en Chrome het in principe al draaiende hebben op de stable versions.

Het gaat zo verrekte traag bij IE team om de W3C standaarden te implementeren. Het ontwikkel team is gewoon trager als bij FireFox en Chrome.

[Loller1]

Lang niet alles in die test is bedoeld om standaard te worden. Daarbij is iets dat nog in ontwikkeling is, Geen standaard. Als ontwikkelaar zou je moeten weten dat de HTML 5 test niet dicht bij representatief komt, het controllers niet eens of de ondersteuning volgens de standaard is...

[Verwijderd]

Probleem is dat htmltest site geen conformance test is maar een arbitraire feature detectie test die over de top punten geeft voor nieuwe bij w3c ingediende features die vaak nog veranderen waardoor ze nu eigenlijk helemaal niet standaard conform zijn.

Die site zegt niks over de kwaliteit van de ondersteuning of in welke mate de browser zich aan de standaard houdt.

Dit is bijvoorbeeld wel een conformance test die de kwaliteit van de ondersteuning van een standaard test:
http://test262.ecmascript.org/

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[BM]

Dit gaat over de update voor 8.1 he, de score daarvan is nog niet bekend vermoed ik zomaar.

[geertdo]

Daarbij kan wel gezegd worden, dat de html5test, ook kenmerken test die nog niet gestandaardiseerd zijn in de html5 normen

Precies, daarom heb je niets aan die score van html5test.com.

[Pmleader]

Zou hiermee het geheugenprobleem wat optreedt bij tweakers.net ook zijn opgelost?

[maartenv]

Hey lol, ik dacht dat het aan mijn 920 lag, maar jij hebt het dus ook!

Die van mij "crasht naar desktop". Vooral bij het lezen van direct messages.

Op andere sites heb ik hier geen, tot héél zelden last van. Ook sites met veel filmpjes zoals dumpert etc werken naar behoren.

[Reactie gewijzigd door maartenv op 22 juli 2024 23:19]

[Caelorum]

[bug] Site performance op Windows Phone 8.1

[Pataar]

Ik heb er alleen last van met de tweakers app, wat eigenlijk een wrapper is. In IE heb ik er niet echt last van.
Ik gebruik een 920

[Armin]

De Tweakers app (die niet van tweakers zelf is * ) is geen wrapper:

http://www.windowsphone.c...54-e011-854c-00237de2db9e

Er zijn inmiddels wel een aantal anderen bij gekomen die wel gewoon wrappers zijn.

Maar deze leest echt de forum content (en maakt daarbij soms wat foutjes betreft parsen). Het afsluiten hier is omdat dat kennelijk in de UX thread gebeurt en je die niet te lang mag vasthouden. Had men dit in een C# task gedaan, zou die niet afsluiten.

Overigens is het in de laatste versie stukken minder.

*) Nog steeds groot respect voor de maker overigens! Deze app was er al heel vroeg, toen het aantal Nederlandse apps in zijn algemeen nog erg klein was. En hij wordt nog steeds onderhouden.

[Pataar]

Die had ik in het begin ook. Alleen kreeg ik er geen Tweakotine en kon ik geen reacties plaatsen.

[thekingofping]

Ik gebruik geen app maar IE zelf. Ik heb een short cut op mijn beginscherm staan. Nog nooit een crash meegemaakt.

Lumia 920
WP 8.0 (wanneer komt 8.1 nu eens?)

[MAX3400]

Welk geheugenprobleem? Op mijn 8X en Lumia 930 geen enkel probleem met de browser op T.net. Vraag me ook af hoe je het hebt gemeten; ik ken weinig apps die op een non-dev phone het geheugengebruik van andere apps kunnen/mogen meten.

[Pmleader]

Ik heb een lumia 920 dev phone met wp 8.1 DP.
Daarnaast is het een zeer bekend probleem, zie het topic wat caelorum noemt maar...

[trisje]

of het een geheugen probleem is is nog maar de vraag, Maar mijn 920 crashed (IE sluit af) ook zodra er te veel forum moet worden gelezen. die na de artiklen komen. Zonder Forum gaat het prima.

[Brazos]

Is inderdaad een bekend probleem met de dev. preview dat de browser problemen heeft met bepaalde websites (waaronder tweakers) en zichzelf uitschakelt.

De non-dev. preview heeft hier volgens mij geen last van.

[Verwijderd]

Welk probleem dan?

Want ik heb nog niks gemerkt op mijn Nokia 630 ' ik draai cyan stock

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:19]

[Caelorum]

Nee, het probleem is daar waarschijnlijk niet mee opgelost. Zeer waarschijnlijk is het een probleem met de rendering engine en niet een geheugenprobleem of iets anders zoals ook in dit topic duidelijk is geworden: [bug] Site performance op Windows Phone 8.1
Maar gelukkig ziet het er naar uit dat Tweakers zelf iig al een tijdelijke workaround kan gaan doen

[calvinturbo]

Tweakers.net zorgt schijnbaar alleen voor problemen op IE11 @ Windows Phone, niet op Chrome/Firefox op Android of Safari/Chrome op iOS of op IE10 @ Windows Phone.

[Reactie gewijzigd door calvinturbo op 22 juli 2024 23:19]

[Armin]

Of op IE10 + Windows Phone 8 alwaar ik ook geen problemen heb.

Zal denk ik wel komen door de poging van IE11 om de 'isIE()' scripts en andere detectie te ontwijken?

[RayNbow]

Zal denk ik wel komen door de poging van IE11 om de 'isIE()' scripts en andere detectie te ontwijken?

Nee, want het gedrag dat in deze nieuwspost beschreven wordt is nog niet vrijgegeven voor het grotere publiek en is ook niet de oorzaak van de problemen. De problemen van de responsive site van Tweakers hebben iets te maken met bepaalde CSS regels en zowel de huidige IE11 op de desktop als op de huidige WP8.1 hebben er last van. Zie ook: http://gathering.tweakers...message/42634407#42634407

[RagingPenguin]

Het is een bug tussen het respontieve design en IE11. Met een custom css of de desktop weergave heb je bergend last meer van. Op de WP feedbacksite worden er ook meer websites genoemd met problemen icm een respontieve design

[HooksForFeet]

Ook zijn er problemen waar Microsoft nog steeds mee zit. Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles.

Hè? Volgens mij ondersteunt IE11 gewoon Pointer Events, de voorgestelde opvolger van Touch Events die nota bene door Microsoft zelf is aangedragen.

[RayNbow]

Klopt, maar nu emuleert de nieuwe IE11 dus ook de oude Touch Events.

[HooksForFeet]

Maar waarom is dat dan "een probleem van Microsoft"? Dat probleem treedt dan toch op bij alle browsers die Touch Events ondersteunen (oftewel, alle grote browsers)?

Het lijkt mij juist dat Microsoft een minder groot probleem heeft door ook een API (Pointer Events) te ondersteunen waarmee die problemen vermeden kunnen worden.

[Verwijderd]

Het probleem zijn de websites die gebouwd zijn voor de iphone en die nog steeds touch events blijven gebruiken.

[Martinspire]

Klopt, en Tweakers is hiermee dus gewoon fout.

[Blazing-Studios]

_{Ook zijn er problemen waar Microsoft nog steeds mee zit. Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles}
Ik neem aan dat dit dan weer over de desktopbrowser gaat en niet de mobiele browser uit windows phone?

[Chris.nl]

Ik zou het wel mooi vinden als een fullscreen mogelijkheid toegevoegd wordt. Voor mij hoeft de adres-/zoekbalk niet constant in beeld te zijn.

[PolarBear]

Ook zijn er problemen waar Microsoft nog steeds mee zit. Zo heeft IE11 ondersteuning voor touch via Touch Events, een oudere W3C-standaard. Die levert echter problemen op bij apparaten die zowel touch als muis en toetsenbord hebben, zoals convertibles.

http://msdn.microsoft.com...ie/dn304886(v=vs.85).aspx

Pointer events are events and related interfaces that handle hardware agnostic pointer input from devices like a mouse, pen, or touchscreen. Since its premier in Internet Explorer 10, Pointer events has become a World Wide Web Consortium (W3C) specification, thanks to the feedback and support from other browser vendors and the web standards community.

Pointer events worden als beter/superieur gezien tov Touch Events.Het is zoals gezegd een W3C standaard aan het worden. Ik kan nergens vinden dat (mobile) IE van Touch events gebruik maakt.

Zie ook voor meer info: http://blogs.msdn.com/b/d...f-ie10-and-windows-8.aspx

[Reactie gewijzigd door PolarBear op 22 juli 2024 23:19]

[MoietyMe]

Nee lekker is dat, MS die de -webkit- prefix gaat ondersteunen. Hoezo compliance -.-'

[Martinspire]

Slechts voor enkele dingen. Meeste zaken zijn al prima geimplementeerd. Het is eerder de developers die zitten te slapen waardoor sites er niet uit zien op IE soms.
Dan hebben ze wel "-webkit-transition" maar geen "transition"

[Reactie gewijzigd door Martinspire op 22 juli 2024 23:19]