Gebruik van ems in media queries

donderdag 3 oktober 2013 13:43

Ja, ik denk dat text zooming gaat verdwijnen. De meeste mobiele devices doen eigenlijk niks met lettergrootte, je kunt het lang niet altijd instellen, en zoomen is meestal browser zoom.
Text zoom breekt bovendien de verhouding tussen afbeeldingen en tekst.

Overigens is het mijn praktische ervaring dat het 'tekst instellen door de gebruikers' een mixed blessing is. Voor een aantal mensen handig, maar ook genoeg gebruikers die het niet snappen. En die dus met een site zitten met letters die veel groter of kleiner zijn dan verwacht. Jammer is dat, maar het kan veel weerstand oproepen.

Bovendien is er nog geen echte overeenstemming hoe groot 1 em moet zijn: op standaardinstellingen is 1 em meestal niet het formaat van een prettig leesbaar basislettertype. (Het wordt eigenlijk standaard gecodeerd naar 16px - ongeacht device.)

Verder zijn ems zelf in gebruik soms irritant. De problemen met overerving worden wel opgevangen door rems, maar heeft nog een fallback nodig zolang IE8 niet dood en begraven is.

Edit: neemt niet weg dat er veel mogelijk is.

Never explain with stupidity where malice is a better explanation

Acties:

RM-rf

1 2 3 4 5 7 6 8 9

Omdat het een verantwoordelijkheid van vormgevers is ontwerpen te maken ...

het is al lastig die uit te leggen dat de venstergrootte en devices kunnen wijzigen en verschillen uitmaken...

Hoelang denk je dat het kost om een vormgever uit te leggen dat zaken als breedtes en hoogtes van elementen dan opeens ook geheel veranderbaar zou moeten zijn op basis van een gebruikersinstelling..

Waarbij overigens de verre meerderheid van de gebruikers geen tot weinig kennis, en misschien nóg belangrijker geen behoefte heeft alles zelf te regelen..
stel je voor dat je die gebruiker ook continue moet uitleggen dat ze bepaale bezwaren over 'te klein' of 'te groot' zelf moeten oplossen via hun persoonlijke instellingen...

Bovendien is er nog geen echte overeenstemming hoe groot 1 em moet zijn: op standaardinstellingen is 1 em meestal niet het formaat van een prettig leesbaar basislettertype. (Het wordt eigenlijk standaard gecodeerd naar 16px - ongeacht device.)

de 'em' is oorspronkelijk de breedte van de kapitale 'M' in een bepaald lettertype (eigenlijk de breedte van het zetblok, dus vooral een maateenheid waarmee zetters rekenden), dus ook afhankelijk van welk font je kiest..
De webstandaard is dat de fontgrootte gelijk is aan de em, onafhankelijk van font.

ex is wel nog steeds font-afhankelijk.. het is de hoogte van het font-corps zelfs, dus het deel van het lettertype zonder vlaggen en staarten, effectief vaak de hoogte van de letter 'x'

Intelligente mensen zoeken in tijden van crisis naar oplossingen, Idioten zoeken dan schuldigen

zaterdag 5 oktober 2013 16:31

Acties:

Y0ur1

Topicstarter

RM-rf schreef op donderdag 03 oktober 2013 @ 13:43:
Hoelang denk je dat het kost om een vormgever uit te leggen dat zaken als breedtes en hoogtes van elementen dan opeens ook geheel veranderbaar zou moeten zijn op basis van een gebruikersinstelling..

Dat het web steeds meer responsive wordt is een feit en daar moeten ontwerper ook rekening mee houden in hun ontwerpen. Of die ontwerpen nou veranderen voor de neus van de gebruiker door de grootte van de viewport of door de ingestelde lettergrootte van de gebruiker zou voor een ontwerper niks uit moeten maken. Met media queries gebaseed op ems is dit dus prima mogelijk.

Ik snap dat browser zooming veel simpeler is voor de gebruiker en op alle websites werkt maar ik vraag me toch af hoe het met de text zoom gaat aflopen.

@incaz
Je hebt inderdaad goede punten. Het enige is dat ik het werken met ems niet al nadeel beschouw maar als voordeel. Ja het is wat meer werk, en zeker de overerving kan soms vervelend zijn maar per saldo levert het je zo veel meer flexibiliteit op dat het wat mij betreft de moeite waard is.

zaterdag 5 oktober 2013 18:14

Acties:

maandag 7 oktober 2013 10:34

Overigens: een argument voor text-zoom wordt hier gegeven: http://stackoverflow.com/...9517/why-em-instead-of-px
"That's because they use the simplest zoom method: scaling the entire page. But it means at 150% zoom, a 1000px wide page becomes 1500px wide."

Dit treedt zeker op, maar is te verhelpen door geen fixed width in te stellen, maar te werken met een fluid design (al dan niet binnen breakpoints.) Dat maakt de text zoom minder nodig, omdat de site bij scaling niet buiten je beeld valt.
Bovendien worden de breakpoints getriggerd op de softwarematig berekende pixels, dus een extreem ingezoomde desktopbrowser krijgt de mobiele layout. (Althans, in moderne desktopbrowsers. IE8 doet uiteraard niet mee wegens gebrek aan mediaqueries, en mobiele browsers reflowen over het algemeen niet bij zoom.)

Dat heeft andere consequenties, maar hoeft in elk geval niet minder flexibel of toegankelijk te zijn.

Never explain with stupidity where malice is a better explanation

Acties:

maandag 7 oktober 2013 10:45

Ja, en kaal

Bovendien worden de breakpoints getriggerd op de softwarematig berekende pixels, dus een extreem ingezoomde desktopbrowser krijgt de mobiele layout.

Dat zijn css-pixels

[ Voor 5% gewijzigd door _Thanatos_ op 07-10-2013 10:34 ]

日本！🎌

Acties:

maandag 7 oktober 2013 20:53

Ik vind het helemaal prima hoe ze genoemd worden

Goeie uitleg idd, maar ik betwijfel of het de officiele term is.

Never explain with stupidity where malice is a better explanation

Acties:

R4gnax

incaz schreef op maandag 07 oktober 2013 @ 10:45:
Ik vind het helemaal prima hoe ze genoemd worden Goeie uitleg idd, maar ik betwijfel of het de officiele term is.

Officieel heet deze eenheid gewoon de pixel unit en de ratio tussen één pixel en de physieke device pixel dient te worden bepaald via een geijkte reference pixel maat. (Zie: CSS Values and Units Module Level 3)

Alleen is het wel zo dat veel frontend web developers in deze context eigenlijk altijd aan de pixel unit refereren via de term 'css pixel' of 'logical pixel' als een meer directe tegenhanger van de term 'device pixel' of 'physical pixel'. Het is geen officiële term, maar een ad hoc standaard die dat soort discussies wat duidelijk houdt.

dinsdag 8 oktober 2013 09:40

Acties:

jdemaat

Interessante vraag!

Om eerlijk te zijn heb ik zelf nog nooit text zooming gebruikt (is dat gewoon het omhoog draaien van je standaard font grootte?), en als ik al zoom dan is het inderdaad page zoom.

Los daarvan is het mij als ontwikkelaar ook eigenlijk nog nooit gevraagd, zowel freelance als in het bedrijf niet.
Zeker op mobile en tablet is de functie denk ik obsolete geworden, doordat je gewoon in/uit kan pinchen om te zoomen.

Vandaar dat ik mij recent juist het tegenovergestelde afvroeg. Is het echt nog nodig om met em's te werken? De problemen van overerving en dergelijke zijn mij altijd een doorn in het oog. Dat Foundation 4 nu een functie gebruikt genaamd emCalc(px) die pixels voor je omrekent in em's, geeft al aan dat het concept van em's voor ontwikkelaars (de mens) eigenlijk niet logisch werkt.

Rem's lijken mij inderdaad vele malen interessanter. 1 root getal waar de rest van de "ems" vanaf hangt, zonder het erf-concept. Klinkt simpel en doeltreffend, en text zooming blijft behouden.

Edit: de omrekenfunctie is natuurlijk SASS, geen CSS.

[ Voor 2% gewijzigd door jdemaat op 08-10-2013 09:42 . Reden: Verduidelijking ]

dinsdag 8 oktober 2013 10:56

Acties:

dinsdag 8 oktober 2013 12:07

*zucht*

Die functie is ook voornamelijk vanuit toegankelijkheid belangrijk. Of je die vraag hebt gekregen hangt dus heel erg af voor wat voor klanten je werkt. Als je regelmatig projecten doet voor (semi-)overheidsinstanties, dan zul je die vraag ook zeer regelmatig krijgen.

Fontgroottes met em's is vooral even een mind switch. Je kunt niet onbeperkt gaan nesten, want dan wordt het een zooitje, dus begin met een goede baseline bijvoorbeeld en probeer het aantal mutaties daarop tot 1 te beperken.

Los van die discussie, ging deze vooral over het gebruik van em's voor media queries. En daarmee de vraag of je wilt dat je layout verandert als mensen hun frontgrootte (of zoomniveau) aanpassen. Het probleem daarmee is dat je vaak niet alleen van layout switcht, maar ook van content en navigatiemethode (je gaat je meer focussen op touch en grotere hit area's). En daar zit iemand die alleen wat grotere tekst wil misschien wel helemaal niet op te wachten.

Acties:

dinsdag 8 oktober 2013 13:07

Bosmonster schreef op dinsdag 08 oktober 2013 @ 10:56:
Die functie is ook voornamelijk vanuit toegankelijkheid belangrijk.

Dat was het argument, maar gaat dat nog steeds op? Wat biedt text-zoom aan toegankelijkheid die de moderne page-zoom in combinatie met een goede opzet (dus een pagina die niet meteen uit het beeld valt) niet biedt?

Never explain with stupidity where malice is a better explanation

Acties:

dinsdag 8 oktober 2013 13:15

Ja, en kaal

incaz schreef op dinsdag 08 oktober 2013 @ 12:07:
[...]

Dat was het argument, maar gaat dat nog steeds op? Wat biedt text-zoom aan toegankelijkheid die de moderne page-zoom in combinatie met een goede opzet (dus een pagina die niet meteen uit het beeld valt) niet biedt?

Het verschil is dat een page zoom de pagina breder dan het scherm kan maken. Een text zoom behoudt de layout en maakt de tekst (en regelhoogte) groter. Het verschil is subtiel, maar in gebruik denk ik dat text zoom een min-of-meer permanente instelling is, terwijl page zoom een tijdelijk effect is.

Het is niet zo dat je óf de een óf de ander gebruikt (of móet gebruiken, of moet ondersteunen). De twee bestaan naast elkaar met verschillende functies. Als je echt zo'n vergelijking wil maken "de een of de ander", kun je het net zo goed omdraaien: waarom is er een page zoom als je met text zoom i.c.m. een goeie opzet, precies hetzelfde kunt bereiken?..

日本！🎌

Acties:

dinsdag 8 oktober 2013 20:54

*zucht*

De fontgrootte is ook niet direct een zoom-mogelijkheid. Het is ook iets dat door het OS geregeld kan worden , bijvoorbeeld door grotere letters in te stellen, iets wat mensen met een visuele beperking vaak standaard hebben.

Acties:

donderdag 10 oktober 2013 11:18

Niet om het een of het ander, maar mijn OS biedt ook 'make everything larger' (dus inclusief icoontjes en plaatjes ed) prominenter aan dan het vergroten van de tekst. Daar is blijkbaar behoefte aan.

Em was in de oudere browserimplementaties belangrijk. Het gebruiken van px had een aantal concrete nadelen tav accessibility. Maar browsers veranderen (behalve IE8) en in de praktijk blijkt dat de browsers en os'en een groot deel van die nadelen hebben ondervangen. Met fluid design kun je een paar van de overgebleven nadelen oplossen.

Op dit moment denk ik dat em-based op zich prima kan, zeker bij nieuwe websites. Het inpassen in een bestaande structuur is niet altijd triviaal (soms heb je niet zoveel controle over nesting, tenzij je je hele framework ondersteboven gooit bv.) Maar dat is nog niet voldoende reden om het beter te vinden dan px-based. En theorie/principe alleen is wat dat betreft toch net een wat te magere basis.

Ik ben op beslist geinteresseerd in een hele concrete en heldere use case waarin je wel de tekst maar niet de afbeeldingen geschaald wilt hebben, en dus waarin text zoom belangrijker is dan full zoom. Maar de voorbeelden die tot nu toe gegeven zijn, overtuigen mij nog niet.

Never explain with stupidity where malice is a better explanation

Acties:

donderdag 10 oktober 2013 11:40

Ja, en kaal

Bosmonster schreef op dinsdag 08 oktober 2013 @ 13:15:
De fontgrootte is ook niet direct een zoom-mogelijkheid. Het is ook iets dat door het OS geregeld kan worden , bijvoorbeeld door grotere letters in te stellen, iets wat mensen met een visuele beperking vaak standaard hebben.

Iets wat laptops met een HDPI scherm ook standaard hebben. De mijne staat op 140% (1920x1080 op 13").

Maar genoeg tablets en telefoons die de standaard text-zoom van de browser-app ook standaard op iets anders dan 100% hebben staan. Samsung bijvoorbeeld, die er een handje van heeft om werkelijk enorme fonts te gebruiken in hun devices.

incaz schreef op dinsdag 08 oktober 2013 @ 20:54:
Niet om het een of het ander, maar mijn OS biedt ook 'make everything larger' (dus inclusief icoontjes en plaatjes ed) prominenter aan dan het vergroten van de tekst. Daar is blijkbaar behoefte aan.

In je OS en in normale applicaties wordt alles dan groter (in theorie dan, er zijn altijd applicaties die de setting aan hun aars lappen). Maar in een browser is "1px" dan nog steeds 1 fysieke pixel. Althans, in Windows is dat zo.

[ Voor 49% gewijzigd door _Thanatos_ op 10-10-2013 11:22 ]

日本！🎌

Acties:

donderdag 10 oktober 2013 23:16

In mijn Win8 is 'make everything larger' ook echt 'everything'. Ook binnen browsers. Dus geen fysieke pixels.

Never explain with stupidity where malice is a better explanation

Acties:

jdemaat

_Thanatos_ schreef op dinsdag 08 oktober 2013 @ 13:07:
Het verschil is dat een page zoom de pagina breder dan het scherm kan maken. Een text zoom behoudt de layout en maakt de tekst (en regelhoogte) groter. Het verschil is subtiel, maar in gebruik denk ik dat text zoom een min-of-meer permanente instelling is, terwijl page zoom een tijdelijk effect is.

Dat kán, maar aangezien we allemaal natuurlijk mooie fluid responsive designs maken hoort dat niet te gebeuren.

Daarbij krijg je namelijk bij page zoom gewoon de aangepaste (mobile) layout als de site te breed wordt.

Overigens is page zoom in ieder geval in Chrome wel een permanente instelling per website, in die zin dat je instelling dus onthouden blijft.

vrijdag 11 oktober 2013 09:03

Acties:

dinsdag 15 oktober 2013 13:03

*zucht*

_Thanatos_ schreef op donderdag 10 oktober 2013 @ 11:18:
[...]

Iets wat laptops met een HDPI scherm ook standaard hebben. De mijne staat op 140% (1920x1080 op 13").

Dat doen alleen OS'en die geen fatsoenlijke HDPI modus hebben

Acties:

dinsdag 15 oktober 2013 13:22

Ja, en kaal

Bosmonster schreef op vrijdag 11 oktober 2013 @ 09:03:
[...]

Dat doen alleen OS'en die geen fatsoenlijke HDPI modus hebben

Wat bedoel je daarmee? Ga je me vertellen dat Windows 7 geen fasoenlijke HDPI support heeft, of kun je ook gewoon accepteren dat het de applicaties zijn die nogaleens deze setting overriden?

Terug naar het topic, als je gaat inzoomen om even dat ene elementje beter te kunnen zien, lijkt het je dan niet vreselijk irritant als de hele site een compleet andere layout krijgt? Page zoom is bedoeld voor inzoomen, en alléén inzoomen. Het is iets dat je zelf doet (hoewel het onthouden kan worden - dat is schijnbaar aan de browser) om vervolgens in twee rihtingen te kunnen scrollen en de site afscannen.

Net als pinch-to-zoom op je mobieltje. Of moet dan de site ook gaan lopen relayouten om maar te blijven passen? Dat lijkt me dus vreselijk irritant.

日本！🎌

Acties:

dinsdag 15 oktober 2013 13:36

*zucht*

_Thanatos_ schreef op dinsdag 15 oktober 2013 @ 13:03:
[...]

Wat bedoel je daarmee? Ga je me vertellen dat Windows 7 geen fasoenlijke HDPI support heeft, of kun je ook gewoon accepteren dat het de applicaties zijn die nogaleens deze setting overriden?

Uhh... HiDPI-support komt pas in Windows 8.1.

Je fonts groter zetten heeft natuurlijk helemaal niks met een OS-wide HiDPI modus te maken. Dat heeft te maken met het feit dat het OS een hogere pixel density ondersteunt en dat doet Windows 7 en zelfs Windows 8 niet.

Acties:

dinsdag 15 oktober 2013 21:18

_Thanatos_: waar staat precies omschreven wat 'de bedoeling' is van pagezoom? Is dat vastgelegd in W3C-specs?

(De oplossing lijkt me trouwens ook simpel: vervang de keuze tussen text zoom en page zoom door een keuze tussen scale met en zonder reflow.)

Never explain with stupidity where malice is a better explanation

Acties:

woensdag 16 oktober 2013 08:43

Ja, en kaal

Bosmonster schreef op dinsdag 15 oktober 2013 @ 13:22:
[...]

Uhh... HiDPI-support komt pas in Windows 8.1.

Je fonts groter zetten heeft natuurlijk helemaal niks met een OS-wide HiDPI modus te maken. Dat heeft te maken met het feit dat het OS een hogere pixel density ondersteunt en dat doet Windows 7 en zelfs Windows 8 niet.

Het is maar hoe je het bekijkt. Alles in Windows wordt groter als je voor large fonts gaat. Niet alleen de fonts, gek genoeg, maar ook iconen en widgets en allerlei schermelementen. Het meeste schaalt keurig zonder pixels op te blazen, dus zonder blur.

Ik weet niet wat HDPI-support in Windows 8.1 dan opeens zo verschrikkelijk anders maakt, maar "large fonts" is bedoeld voor HDPI-schermen en bestaat al sinds Windows 95, afaik. Alleen pas vanaf Vista werkt het enigzins goed. Grote probleem is dat er nog steeds applicaties zijn (zoals Skype

) die deze setting overrulen, maar dat kan met Windows 8.1 natuurlijk nog steeds zo zijn.

Ik denk dat er hoe dan ook een misverstand is over wat HDPI-support betekent. Voor mij betekent het dat ik zonder te turen op een HDPI-scherm op Windows 7 m'n werk kan doen, voor jou is het schijnbaar iets hippers dan dat.

incaz schreef op dinsdag 15 oktober 2013 @ 13:36:
_Thanatos_: waar staat precies omschreven wat 'de bedoeling' is van pagezoom? Is dat vastgelegd in W3C-specs?

(De oplossing lijkt me trouwens ook simpel: vervang de keuze tussen text zoom en page zoom door een keuze tussen scale met en zonder reflow.)

Onhandige woordkeuze

(en niet alles zo letterlijk nemen)
Maar het gaat me erom dat als je gaat inzoomen dat het onhandig is dat de hele pagina anders wordt en je niet meer terug kunt vinden op wel stuk je nou inzoomde. Of zou je het handig vinden dat als je met je iPad pincht om in te zoomen naar, zeg, 200%, dat je dan opeens overschakelt naar de smartphone-layout? Of als je je 24 inch desktopmonitor hebt en em even in de achteroverleunstand op 170% zoom zet, ineens alles onder elkaar klapt? Dat kan niet "de bedoeling" zijn van zoomen.

Daarom ben ik ervoor om breakpoints te koppelen aan pixels. Pixels horen bij een schermgrootte, onafhankelijk van de tekstgrootte. Tekst kun je ook zoomen, maar je zorgt natuurlijk dat je design dynamisch genoeg is om dat op te vangen.

日本！🎌

Acties:

woensdag 16 oktober 2013 10:40

Het is niet letterlijk bedoeld, maar het is nuttig om je te bedenken wat de use cases zijn. Jij kunt dingen wel niet 'de bedoeling' vinden, maar hoe gaat het in het gebruik?

Zo zie je dat er een groot verschil is in voorkeur tussen kleine en grote schermen: op kleine schermen is zoomen vaak om een detail uit te vergroten, terwijl dat op desktops meestal niet speelt.

Jouw voorbeeld van 170% op een 24inch is enerzijds een slecht voorbeeld: je zet je mediaquerie (em of px of wat dan ook) niet op zoomlevel maar op beschikbare schermgrootte... en die is ook bij 170% nog gigantisch dus de kans dat de mobiele layout wordt getriggerd is niet zo groot.
Van de andere kant is het een aardig voorbeeld, omdat je juist in de achteroverleunstand met wat grotere letters vast geen zin hebt om horizontaal te scrollen. Full zoom en reflow is daar dus een prima oplossing.

Daartegenover staat de gebruikservaring op kleine schermen, waar je als je details wilt bekijken inderdaad je context niet zomaar kwijt wilt raken.

Als je daarnaar kijkt zou je dus tot de conclusie komen dat er twee zoombehoeften zijn: pinch-zoom die gewoon plaatselijk vergroot zonder reflow (vooral voor kleine schermen, maar met behulp van het vergrootglas ook beschikbaar op desktop), en een algemene zoom die wel reflowt.
Dat het belangrijk is om tekst afzonderlijk te kunnen zoomen blijkt er dan weer niet uit: het lijkt volkomen acceptabel (en accessible) om zowel de tekst als de afbeeldingen te zoomen en niet slechts de tekst. Zoals gezegd: ik ben geinteresseerd in een concrete use case waarin text zoom belangrijk is, maar de voorbeelden die tot nu toe gegeven zijn, illustreren dat niet.

Overigens maakt het voor beide volstrekt niet uit of je em-based of px-based breakpoints gebruikt.

Daarom ben ik ervoor om breakpoints te koppelen aan pixels. Pixels horen bij een schermgrootte,

Dit klopt niet, je hebt vanuit je css geen toegang tot de device pixels, en over de css-pixels / softwarematig berekende pixels wordt flink gelogen door browsers. Zo zetten tablets (en foons?) dit vaak op 960 als je geen viewport meegeeft, en verandert het bij zoomlevel op desktop.

Never explain with stupidity where malice is a better explanation

Acties:

woensdag 16 oktober 2013 19:18

*zucht*

_Thanatos_ schreef op dinsdag 15 oktober 2013 @ 21:18:
[...]

Ik weet niet wat HDPI-support in Windows 8.1 dan opeens zo verschrikkelijk anders maakt, maar "large fonts" is bedoeld voor HDPI-schermen en bestaat al sinds Windows 95, afaik.

Large fonts is een accessibility setting, geen HiDPI setting. Het enkel verhogen van de tekstgrootte heeft natuurlijk ook niks te maken met het verhogen van de pixel density van de gehele user interface. De verhoudingen horen juist gelijk te blijven.

Je kunt ook gewoon zelf even Googlen natuurlijk over HiDPI in Windows:
http://www.gizmodo.co.uk/...de-for-windows-yesterday/
http://www.theverge.com/2...dd-retina-display-support

Als je moeite hebt met het begrip HiDPI (of Retina) dan kan ik je aanraden eens een Retina MBP te bekijken van een kennis of bij de Apple Store en te spelen met de verschillende pixel densities / resolutions.

[ Voor 24% gewijzigd door Bosmonster op 16-10-2013 10:44 ]

Acties:

Ramon

Bosmonster schreef op woensdag 16 oktober 2013 @ 10:40:
[...]

Large fonts is een accessibility setting, geen HiDPI setting. Het enkel verhogen van de tekstgrootte heeft natuurlijk ook niks te maken met het verhogen van de pixel density van de gehele user interface. De verhoudingen horen juist gelijk te blijven.

Je kunt ook gewoon zelf even Googlen natuurlijk over HiDPI in Windows:
http://www.gizmodo.co.uk/...de-for-windows-yesterday/
http://www.theverge.com/2...dd-retina-display-support

Als je moeite hebt met het begrip HiDPI (of Retina) dan kan ik je aanraden eens een Retina MBP te bekijken van een kennis of bij de Apple Store en te spelen met de verschillende pixel densities / resolutions.

Beide artikelen lijken meer op FUD dan iets anders. Bijvoorbeeld de Surface Pro komt op Windows 8 draaiend op een DPI setting van 150% out of the box. Dus dit plaatje is gewoon heel erg fout. Dit geldt voor zover ik weet voor alle Windows 8 devices, Windows 8 weet de scherm-grootte en de resolutie en past daar zelf de DPI% op aan. Hetzelfde geldt voor het tweede artikel, gewoon heel erg veel fouten, maar dat is te verwachten van theverge.com, waar MS reporting altijd biased is.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

donderdag 17 oktober 2013 09:37

Acties: