Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
W3C publiceert eerste ontwerp van "HTML Responsive Images Extension"
13 views
Skip to first unread message
SF
Dec 23, 2012, 10:01:58 AM12/23/12
to
Interessante ontwikkeling :
http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
met markup worden verschillende formaten van plaatjes tot stand gebracht
Dit is het format wat voorgesteld wordt:
1 <picture alt="">
2 <source media="(min-width: 45em)" srcset="large-1.jpg 1x,
large-2.jpg 2x">
3 <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
4 <source srcset="small-1.jpg 1x, small-2.jpg 2x">
5 <img src="small-1.jpg">
6 </picture>
SF
http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
met markup worden verschillende formaten van plaatjes tot stand gebracht
Dit is het format wat voorgesteld wordt:
1 <picture alt="">
2 <source media="(min-width: 45em)" srcset="large-1.jpg 1x,
large-2.jpg 2x">
3 <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
4 <source srcset="small-1.jpg 1x, small-2.jpg 2x">
5 <img src="small-1.jpg">
6 </picture>
SF
robert
Dec 23, 2012, 2:14:12 PM12/23/12
to
SF <S...@iets.nl>:
http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
--
robert
> Interessante ontwikkeling :
> http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>
> met markup worden verschillende formaten van plaatjes tot stand gebracht
Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
> http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>
> met markup worden verschillende formaten van plaatjes tot stand gebracht
http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
--
robert
SF
Dec 23, 2012, 3:42:47 PM12/23/12
to
Op 23-12-2012 20:14, robert schreef:
o dank je goed idee!
SF
SF
Roland van Ipenburg
Dec 28, 2012, 7:39:50 AM12/28/12
to
On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
Voor welk probleem is dat een oplossing?
Het eerste gerelateerde probleem is dat je iemand op
bijvoorbeeld een EDGE verbinding geen zware retina images
voor een groot scherm wilt sturen. Vroeger kon je dat nog
proberen door er van uit te gaan dat kleine schermpjes op
een trage verbinding zaten, tegenwoordig is die correlatie
veel minder en is het zonder media queries die onder andere
een redelijk goede voorspelling van de snelheid van de
verbinding geven wishful thinking dat dit probleem met CSS
kan worden opgelost.
Daarnaast geeft dit ook geen antwoord in een mobile first
benadering: Als stukken van een plaatje weg kunnen worden
gelaten op een kleiner scherm, waarom zouden die er dan op
een groter scherm überhaupt aan toegevoegd moeten worden?
Ook al heb je een focal point dan is het nog lastig om in te
zien op welk moment de essentie van een afbeelding niet meer
overkomt, en waarom je daar dan nog een deel van dezelfde
afbeelding voor zou willen gebruiken.
--
Roland van Ipenburg
roland.va...@xs4all.nl
http://ipenburg.home.xs4all.nl/
"Pooh Styx?"
Het eerste gerelateerde probleem is dat je iemand op
bijvoorbeeld een EDGE verbinding geen zware retina images
voor een groot scherm wilt sturen. Vroeger kon je dat nog
proberen door er van uit te gaan dat kleine schermpjes op
een trage verbinding zaten, tegenwoordig is die correlatie
veel minder en is het zonder media queries die onder andere
een redelijk goede voorspelling van de snelheid van de
verbinding geven wishful thinking dat dit probleem met CSS
kan worden opgelost.
Daarnaast geeft dit ook geen antwoord in een mobile first
benadering: Als stukken van een plaatje weg kunnen worden
gelaten op een kleiner scherm, waarom zouden die er dan op
een groter scherm überhaupt aan toegevoegd moeten worden?
Ook al heb je een focal point dan is het nog lastig om in te
zien op welk moment de essentie van een afbeelding niet meer
overkomt, en waarom je daar dan nog een deel van dezelfde
afbeelding voor zou willen gebruiken.
--
Roland van Ipenburg
roland.va...@xs4all.nl
http://ipenburg.home.xs4all.nl/
"Pooh Styx?"
robert
Dec 28, 2012, 7:53:10 AM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl>:
waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke deel
ervan is.
> Het eerste gerelateerde probleem is dat je iemand op bijvoorbeeld een
> EDGE verbinding geen zware retina images voor een groot scherm wilt
> sturen. Vroeger kon je dat nog proberen door er van uit te gaan dat
> kleine schermpjes op een trage verbinding zaten, tegenwoordig is die
> correlatie veel minder en is het zonder media queries die onder andere
> een redelijk goede voorspelling van de snelheid van de verbinding geven
> wishful thinking dat dit probleem met CSS kan worden opgelost.
Het gaat hier niet over langzame verbindingen, het gaat om verschillende
schermgroottes en *een* manier om daarmee om te gaan. Als je graag een
oplossing wilt voor het beperken van filesize voor EDGE-gebruikers:
http://blog.netvlies.nl/design-interactie/retina-revolution/
> Daarnaast geeft dit ook geen antwoord in een mobile first benadering: Als
> stukken van een plaatje weg kunnen worden gelaten op een kleiner scherm,
> waarom zouden die er dan op een groter scherm überhaupt aan toegevoegd
> moeten worden?
Wie zegt dat 'mobile first' een goede oplossing is voor iedereen?
--
robert
> On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>> SF <S...@iets.nl>:
>>> Interessante ontwikkeling
>>> : http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>
>>> met markup worden verschillende formaten van plaatjes tot stand
>>> gebracht
>>
>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>
> Voor welk probleem is dat een oplossing?
Voor kleine schermen waar je niet aparte plaatjes voor wilt gaan pushen, en
> mentioned:
>> SF <S...@iets.nl>:
>>> Interessante ontwikkeling
>>> : http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>
>>> met markup worden verschillende formaten van plaatjes tot stand
>>> gebracht
>>
>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>
> Voor welk probleem is dat een oplossing?
waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke deel
ervan is.
> Het eerste gerelateerde probleem is dat je iemand op bijvoorbeeld een
> EDGE verbinding geen zware retina images voor een groot scherm wilt
> sturen. Vroeger kon je dat nog proberen door er van uit te gaan dat
> kleine schermpjes op een trage verbinding zaten, tegenwoordig is die
> correlatie veel minder en is het zonder media queries die onder andere
> een redelijk goede voorspelling van de snelheid van de verbinding geven
> wishful thinking dat dit probleem met CSS kan worden opgelost.
schermgroottes en *een* manier om daarmee om te gaan. Als je graag een
oplossing wilt voor het beperken van filesize voor EDGE-gebruikers:
http://blog.netvlies.nl/design-interactie/retina-revolution/
> Daarnaast geeft dit ook geen antwoord in een mobile first benadering: Als
> stukken van een plaatje weg kunnen worden gelaten op een kleiner scherm,
> waarom zouden die er dan op een groter scherm überhaupt aan toegevoegd
> moeten worden?
--
robert
Rob
Dec 28, 2012, 8:37:59 AM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl> wrote:
> On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
>> SF <S...@iets.nl>:
>>> Interessante ontwikkeling :
>>> http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>
>>> met markup worden verschillende formaten van plaatjes tot stand gebracht
>>
>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>
> Voor welk probleem is dat een oplossing?
>
> Het eerste gerelateerde probleem is dat je iemand op
> bijvoorbeeld een EDGE verbinding geen zware retina images
> voor een groot scherm wilt sturen. Vroeger kon je dat nog
> proberen door er van uit te gaan dat kleine schermpjes op
> een trage verbinding zaten, tegenwoordig is die correlatie
> veel minder en is het zonder media queries die onder andere
> een redelijk goede voorspelling van de snelheid van de
> verbinding geven wishful thinking dat dit probleem met CSS
> kan worden opgelost.
Ik denk ook dat dit een probleem is wat beter door de gebruiker
> On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
>> SF <S...@iets.nl>:
>>> Interessante ontwikkeling :
>>> http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>
>>> met markup worden verschillende formaten van plaatjes tot stand gebracht
>>
>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>
> Voor welk probleem is dat een oplossing?
>
> Het eerste gerelateerde probleem is dat je iemand op
> bijvoorbeeld een EDGE verbinding geen zware retina images
> voor een groot scherm wilt sturen. Vroeger kon je dat nog
> proberen door er van uit te gaan dat kleine schermpjes op
> een trage verbinding zaten, tegenwoordig is die correlatie
> veel minder en is het zonder media queries die onder andere
> een redelijk goede voorspelling van de snelheid van de
> verbinding geven wishful thinking dat dit probleem met CSS
> kan worden opgelost.
en zijn provider kan worden opgelost. Er zijn transparante
proxies die je als mobiele gebruiker kunt inschakelen door
een bepaalde APN te kiezen, en die on-the-fly zowel de HTML
als de plaatjes comprimeren en verkleinen. Dat vind ik een
goede oplossing, waar de websitebouwer niet mee wordt lastig
gevallen.
Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
gebruikers te maken maar de mobiele browsers doen juist pogingen
om dat soort detectie te omzeilen en zich als volwaardige
desktop voor te stellen. Dan maar niet.
robert
Dec 28, 2012, 8:56:45 AM12/28/12
to
Rob <nom...@example.com>:
--
robert
> Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
> soort detectie te omzeilen en zich als volwaardige desktop voor te
> stellen.
"media queries". Niet zelf gaan prutten met browserherkenning of zo.
> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
> soort detectie te omzeilen en zich als volwaardige desktop voor te
> stellen.
--
robert
Roland van Ipenburg
Dec 28, 2012, 9:09:18 AM12/28/12
to
On 28 Dec 2012 12:53:10 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
> Wie zegt dat 'mobile first' een goede oplossing is voor iedereen?
"Mobile first" is geen oplossing, het is een methode die
inzicht geeft in wat de gevolgen van responsive voor de
content zouden kunnen zijn. Het zou inzicht moeten geven in
hoe belangrijk het eigenlijk is dat je geen aparte plaatjes
wilt pushen en beperkt bent tot het aangeven van focal
points in vergelijking tot bijvoorbeeld het managen van een
set custom content voor verschillende media. Zonder dat
inzicht blijft responsive een workaround voor niet optimale
content.
> Roland van Ipenburg <roland.va...@xs4all.nl>:
>> On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>> mentioned:
>>> SF <S...@iets.nl>:
>>>> Interessante ontwikkeling
>>>> : http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>>
>>>> met markup worden verschillende formaten van plaatjes tot stand
>>>> gebracht
>>>
>>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>>
>> Voor welk probleem is dat een oplossing?
>
> Voor kleine schermen waar je niet aparte plaatjes voor wilt gaan pushen, en
> waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke deel
> ervan is.
…
>> On 23 Dec 2012 19:14:12 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>> mentioned:
>>> SF <S...@iets.nl>:
>>>> Interessante ontwikkeling
>>>> : http://www.webmonkey.com/2012/08/w3c-proposes-responsive-image-solution
>>>>
>>>> met markup worden verschillende formaten van plaatjes tot stand
>>>> gebracht
>>>
>>> Wat ik zelf wel een leuke oplossing vind, die nu al werkt:
>>> http://designshack.net/articles/css/focal-point-intelligent-cropping-of-responsive-images/
>>
>> Voor welk probleem is dat een oplossing?
>
> Voor kleine schermen waar je niet aparte plaatjes voor wilt gaan pushen, en
> waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke deel
> ervan is.
> Wie zegt dat 'mobile first' een goede oplossing is voor iedereen?
inzicht geeft in wat de gevolgen van responsive voor de
content zouden kunnen zijn. Het zou inzicht moeten geven in
hoe belangrijk het eigenlijk is dat je geen aparte plaatjes
wilt pushen en beperkt bent tot het aangeven van focal
points in vergelijking tot bijvoorbeeld het managen van een
set custom content voor verschillende media. Zonder dat
inzicht blijft responsive een workaround voor niet optimale
content.
robert
Dec 28, 2012, 9:20:10 AM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl>:
> On 28 Dec 2012 12:53:10 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>
> On 28 Dec 2012 12:53:10 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>
>> Voor kleine schermen waar je niet aparte plaatjes voor wilt gaan pushen,
>> en waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke
>> deel ervan is.
>
> …
>
>> Wie zegt dat 'mobile first' een goede oplossing is voor iedereen?
>
> "Mobile first" is geen oplossing, het is een methode die inzicht geeft in
> wat de gevolgen van responsive voor de content zouden kunnen zijn.
"Mobile first" gaat veel verder dan dat, het gaat om het ontwikkelen van
>> en waarbij je makkelijk per plaatje kunt aangeven wat het belangrijke
>> deel ervan is.
>
> …
>
>> Wie zegt dat 'mobile first' een goede oplossing is voor iedereen?
>
> "Mobile first" is geen oplossing, het is een methode die inzicht geeft in
> wat de gevolgen van responsive voor de content zouden kunnen zijn.
(native/web) applicaties die je eerst voor mobiel maakt en pas op een later
tijdstip (of helemaal niet) naar desktop port. En dat is voor velen geen
goede oplossing om te gebruiken als je 'alleen' een responsive website wilt
(want 'responsive' betekent niet automatisch 'is bedoeld voor mobiel').
--
robert
Roland van Ipenburg
Dec 28, 2012, 9:32:37 AM12/28/12
to
On 28 Dec 2012 13:37:59 GMT, Rob <nom...@example.com> mentioned:
De vraag is ook of je dit soort optimalisatie voor de
eindgebruiker doet of voor een designer die graag ziet dat
het er op een bepaalde manier uitziet zonder dat eigenlijk
met A/B tests is aangetoond dat de eindgebruiker daar
significant voordeel bij heeft. Uiteindelijk hebben andere
partijen dan de designer misschien meer inzicht in wat voor
de gemiddelde eindgebruiker een optimale mix is van
bandbreedte, CPU gebruik en het resultaat op bepaalde
devices en zorgen door de webdeveloper geforceerde
uitzonderingen hierop niet voor een betere ervaring voor de
eindgebruiker.
eindgebruiker doet of voor een designer die graag ziet dat
het er op een bepaalde manier uitziet zonder dat eigenlijk
met A/B tests is aangetoond dat de eindgebruiker daar
significant voordeel bij heeft. Uiteindelijk hebben andere
partijen dan de designer misschien meer inzicht in wat voor
de gemiddelde eindgebruiker een optimale mix is van
bandbreedte, CPU gebruik en het resultaat op bepaalde
devices en zorgen door de webdeveloper geforceerde
uitzonderingen hierop niet voor een betere ervaring voor de
eindgebruiker.
Roland van Ipenburg
Dec 28, 2012, 9:48:57 AM12/28/12
to
On 28 Dec 2012 14:20:10 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
"Mobile first" stelt juist de vraag waarom je alleen een
responsive website zou willen die niet voor mobiel bedoeld
is. Dan kan het antwoord best zijn dat daar een goede reden
voor is, maar dat maakt de methode niet minder mobile first.
Met een redenatie dat iets een goede oplossing is als iemand
die oplossing wil kom je niet zo ver.
responsive website zou willen die niet voor mobiel bedoeld
is. Dan kan het antwoord best zijn dat daar een goede reden
voor is, maar dat maakt de methode niet minder mobile first.
Met een redenatie dat iets een goede oplossing is als iemand
die oplossing wil kom je niet zo ver.
Rob
Dec 28, 2012, 11:07:58 AM12/28/12
to
Er zijn allerlei media queries. Maar mobiele browsers beantwoorden
ze alsof ze een desktop zijn.
De enige die nog een beetje werkt is de resolutie:
"only screen and (max-device-width: 640px)"
bijvoorbeeld. maar ook dat wordt steeds moeilijker gemaakt doordat
mobiele devices steeds grotere resoluties hebben of een virtuele
resolutie opgeven die groter is dan de realiteit.
Rob
Dec 28, 2012, 11:13:18 AM12/28/12
to
te laten en daarmee meer ruimte te krijgen voor tekst, cq
bij de default zoom de tekst leesbaar weer te geven.
Dat lukte kwa stylesheet ook wel, maar het grote probleem
blijkt om dat stylesheet te activeren op mobiele devices.
Ik heb geen zin in moving target jagen met allerlei checks
op substrings van de user agent string.
robert
Dec 28, 2012, 12:20:51 PM12/28/12
to
Rob <nom...@example.com>:
moeten worden?
> De enige die nog een beetje werkt is de resolutie:
>
> "only screen and (max-device-width: 640px)"
>
> bijvoorbeeld. maar ook dat wordt steeds moeilijker gemaakt doordat
> mobiele devices steeds grotere resoluties hebben of een virtuele
> resolutie opgeven die groter is dan de realiteit.
Daar kan je met de viewport meta tag vrij goed mee omgaan.
--
robert
> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>> Rob <nom...@example.com>:
>>> Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
>>> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
>>> soort detectie te omzeilen en zich als volwaardige desktop voor te
>>> stellen.
>>
>> "media queries". Niet zelf gaan prutten met browserherkenning of zo.
>
> Ja dat bedoel ik.
> Er zijn allerlei media queries. Maar mobiele browsers beantwoorden
> ze alsof ze een desktop zijn.
Welke media queries zouden dan specifiek door mobiele browsers beantwoord
>> Rob <nom...@example.com>:
>>> Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
>>> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
>>> soort detectie te omzeilen en zich als volwaardige desktop voor te
>>> stellen.
>>
>> "media queries". Niet zelf gaan prutten met browserherkenning of zo.
>
> Ja dat bedoel ik.
> Er zijn allerlei media queries. Maar mobiele browsers beantwoorden
> ze alsof ze een desktop zijn.
moeten worden?
> De enige die nog een beetje werkt is de resolutie:
>
> "only screen and (max-device-width: 640px)"
>
> bijvoorbeeld. maar ook dat wordt steeds moeilijker gemaakt doordat
> mobiele devices steeds grotere resoluties hebben of een virtuele
> resolutie opgeven die groter is dan de realiteit.
--
robert
Roland van Ipenburg
Dec 28, 2012, 12:22:58 PM12/28/12
to
On 28 Dec 2012 16:13:18 GMT, Rob <nom...@example.com> mentioned:
…
> Mijn doel was om op mobiele devices wat "onnodige opsmuk" weg
> te laten en daarmee meer ruimte te krijgen voor tekst, cq
> bij de default zoom de tekst leesbaar weer te geven.
Als bij de default zoom de tekst niet leesbaar is dan lijkt
mij dat er al iets specifieks gedaan is waardoor dat
veroorzaakt wordt.
> Dat lukte kwa stylesheet ook wel, maar het grote probleem
> blijkt om dat stylesheet te activeren op mobiele devices.
Daarom zou het handiger kunnen zijn om mobiele devices als
default te beschouwen en pas bij werkende media queries CSS
toe te voegen die daar van afwijkt, tenzij je dan hetzelfde
probleem hebt voor je niet mobiele target browsers. Vooral
als je tegelijkertijd buggy mobile devices met een klein
scherm en buggy topsetboxes met een groot scherm moet
ondersteunen heb je weinig mogelijkheden om iets aan een
default te verbeteren.
…
> Mijn doel was om op mobiele devices wat "onnodige opsmuk" weg
> te laten en daarmee meer ruimte te krijgen voor tekst, cq
> bij de default zoom de tekst leesbaar weer te geven.
mij dat er al iets specifieks gedaan is waardoor dat
veroorzaakt wordt.
> Dat lukte kwa stylesheet ook wel, maar het grote probleem
> blijkt om dat stylesheet te activeren op mobiele devices.
default te beschouwen en pas bij werkende media queries CSS
toe te voegen die daar van afwijkt, tenzij je dan hetzelfde
probleem hebt voor je niet mobiele target browsers. Vooral
als je tegelijkertijd buggy mobile devices met een klein
scherm en buggy topsetboxes met een groot scherm moet
ondersteunen heb je weinig mogelijkheden om iets aan een
default te verbeteren.
Rob
Dec 28, 2012, 12:26:37 PM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl> wrote:
> On 28 Dec 2012 16:13:18 GMT, Rob <nom...@example.com> mentioned:
> …
>
>> Mijn doel was om op mobiele devices wat "onnodige opsmuk" weg
>> te laten en daarmee meer ruimte te krijgen voor tekst, cq
>> bij de default zoom de tekst leesbaar weer te geven.
>
> Als bij de default zoom de tekst niet leesbaar is dan lijkt
> mij dat er al iets specifieks gedaan is waardoor dat
> veroorzaakt wordt.
Ja de site is bedoeld voor schermen van minimaal zo'n 1024x768
> …
>
>> Mijn doel was om op mobiele devices wat "onnodige opsmuk" weg
>> te laten en daarmee meer ruimte te krijgen voor tekst, cq
>> bij de default zoom de tekst leesbaar weer te geven.
>
> Als bij de default zoom de tekst niet leesbaar is dan lijkt
> mij dat er al iets specifieks gedaan is waardoor dat
> veroorzaakt wordt.
pixels en er staat teveel tekst op voor zo'n mobieltje.
Maar mobieltjes zijn ook niet de doelgroep.
>> Dat lukte kwa stylesheet ook wel, maar het grote probleem
>> blijkt om dat stylesheet te activeren op mobiele devices.
>
> Daarom zou het handiger kunnen zijn om mobiele devices als
> default te beschouwen en pas bij werkende media queries CSS
> toe te voegen die daar van afwijkt, tenzij je dan hetzelfde
> probleem hebt voor je niet mobiele target browsers. Vooral
> als je tegelijkertijd buggy mobile devices met een klein
> scherm en buggy topsetboxes met een groot scherm moet
> ondersteunen heb je weinig mogelijkheden om iets aan een
> default te verbeteren.
maken van een mobiel device. Dat laat ik aan anderen over.
robert
Dec 28, 2012, 12:27:49 PM12/28/12
to
Rob <nom...@example.com>:
queries voor, en dat werkt over het algemeen prima.
Voorbeelden:
http://twitter.github.com/bootstrap/examples/fluid.html
http://www.getskeleton.com/
http://susy.oddbird.net/
--
robert
> Mijn doel was om op mobiele devices wat "onnodige opsmuk" weg te laten en
> daarmee meer ruimte te krijgen voor tekst, cq bij de default zoom de
> tekst leesbaar weer te geven.
>
> Dat lukte kwa stylesheet ook wel, maar het grote probleem blijkt om dat
> stylesheet te activeren op mobiele devices.
>
> Ik heb geen zin in moving target jagen met allerlei checks op substrings
> van de user agent string.
Elk CSS/HTML framework dat "responsive" zegt te zijn gebruikt daar media
> daarmee meer ruimte te krijgen voor tekst, cq bij de default zoom de
> tekst leesbaar weer te geven.
>
> Dat lukte kwa stylesheet ook wel, maar het grote probleem blijkt om dat
> stylesheet te activeren op mobiele devices.
>
> Ik heb geen zin in moving target jagen met allerlei checks op substrings
> van de user agent string.
queries voor, en dat werkt over het algemeen prima.
Voorbeelden:
http://twitter.github.com/bootstrap/examples/fluid.html
http://www.getskeleton.com/
http://susy.oddbird.net/
--
robert
Rob
Dec 28, 2012, 12:31:22 PM12/28/12
to
robert <US3N37+{n.i.w.o}@gmail.com> wrote:
> Rob <nom...@example.com>:
>> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>>> Rob <nom...@example.com>:
>>>> Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
>>>> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
>>>> soort detectie te omzeilen en zich als volwaardige desktop voor te
>>>> stellen.
>>>
>>> "media queries". Niet zelf gaan prutten met browserherkenning of zo.
>>
>> Ja dat bedoel ik.
>> Er zijn allerlei media queries. Maar mobiele browsers beantwoorden
>> ze alsof ze een desktop zijn.
>
> Welke media queries zouden dan specifiek door mobiele browsers beantwoord
> moeten worden?
handheld
> Rob <nom...@example.com>:
>> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>>> Rob <nom...@example.com>:
>>>> Ik heb wel eens geprobeerd om speciale stylesheets voor mobiele
>>>> gebruikers te maken maar de mobiele browsers doen juist pogingen om dat
>>>> soort detectie te omzeilen en zich als volwaardige desktop voor te
>>>> stellen.
>>>
>>> "media queries". Niet zelf gaan prutten met browserherkenning of zo.
>>
>> Ja dat bedoel ik.
>> Er zijn allerlei media queries. Maar mobiele browsers beantwoorden
>> ze alsof ze een desktop zijn.
>
> Welke media queries zouden dan specifiek door mobiele browsers beantwoord
> moeten worden?
of voor mijn part verzint er iemand een nieuwe
>> De enige die nog een beetje werkt is de resolutie:
>>
>> "only screen and (max-device-width: 640px)"
>>
>> bijvoorbeeld. maar ook dat wordt steeds moeilijker gemaakt doordat
>> mobiele devices steeds grotere resoluties hebben of een virtuele
>> resolutie opgeven die groter is dan de realiteit.
>
> Daar kan je met de viewport meta tag vrij goed mee omgaan.
Net als je een of andere standaard hebt dan verzint er weer iemand
een reden om te liegen en weer een nieuwe laag erop te bouwen waar
ingesteld kan worden hoe er gelogen moet worden. Daar ga ik niet
in mee.
Gelukkig is de site niet zo interessant voor mobiele gebruikers.
Ik negeer ze maar tot de mobiele fabrikanten hun zaakjes op orde
hebben.
robert
Dec 28, 2012, 12:43:19 PM12/28/12
to
Rob <nom...@example.com>:
> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>
>> Welke media queries zouden dan specifiek door mobiele browsers
>> beantwoord moeten worden?
>
> handheld
Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>
>> Welke media queries zouden dan specifiek door mobiele browsers
>> beantwoord moeten worden?
>
> handheld
capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
wat beperktere real estate op schermgebied, niet onder voor z'n
desktop-broers.
>> Daar kan je met de viewport meta tag vrij goed mee omgaan.
>
> Het is een collectie workarounds en kludges die geen einde kent.
--
robert
Roland van Ipenburg
Dec 28, 2012, 2:44:20 PM12/28/12
to
On 28 Dec 2012 17:43:19 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
CPU van een mobile device zorgen er echt wel voor dat de
mogelijkheden van een desktop browser van een orde groter
zijn. Dan gaat het er niet over dat Flash op mobile niet
handig is, maar dat CPU en geheugen intensieve capabilities
ook als ze in HTML, XSLT, CSS of JavaScript getriggered
worden daar niet wenselijk zijn en met een goede reden niet
default aan staan. Hoe vet het voor een developer ook kan
zijn om met een trucje hardware acceleratie te gebruiken,
als daarvoor een extra GPU aangezet moet worden en de accu
sneller leeg raakt is het de vraag of dat de juiste manier
is om met mobile om te gaan.
>>> Daar kan je met de viewport meta tag vrij goed mee omgaan.
>>
>> Het is een collectie workarounds en kludges die geen einde kent.
>
> Het valt erg mee.
Vroeger, toen er nog maar 1 type iPhone bestond leek het
even te werken, nu begint het allemaal redelijk door de mand
te vallen:
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
> Rob <nom...@example.com>:
>> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>>
>>> Welke media queries zouden dan specifiek door mobiele browsers
>>> beantwoord moeten worden?
>>
>> handheld
>
> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
> wat beperktere real estate op schermgebied, niet onder voor z'n
> desktop-broers.
Was het maar waar. Het relatief kleine geheugen en de trage
>> robert <US3N37+{n.i.w.o}@gmail.com> wrote:
>>
>>> Welke media queries zouden dan specifiek door mobiele browsers
>>> beantwoord moeten worden?
>>
>> handheld
>
> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
> wat beperktere real estate op schermgebied, niet onder voor z'n
> desktop-broers.
CPU van een mobile device zorgen er echt wel voor dat de
mogelijkheden van een desktop browser van een orde groter
zijn. Dan gaat het er niet over dat Flash op mobile niet
handig is, maar dat CPU en geheugen intensieve capabilities
ook als ze in HTML, XSLT, CSS of JavaScript getriggered
worden daar niet wenselijk zijn en met een goede reden niet
default aan staan. Hoe vet het voor een developer ook kan
zijn om met een trucje hardware acceleratie te gebruiken,
als daarvoor een extra GPU aangezet moet worden en de accu
sneller leeg raakt is het de vraag of dat de juiste manier
is om met mobile om te gaan.
>>> Daar kan je met de viewport meta tag vrij goed mee omgaan.
>>
>> Het is een collectie workarounds en kludges die geen einde kent.
>
> Het valt erg mee.
even te werken, nu begint het allemaal redelijk door de mand
te vallen:
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
robert
Dec 28, 2012, 3:03:18 PM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl>:
draait.
> Dan gaat het er niet over dat Flash op mobile niet handig is, maar dat
> CPU en geheugen intensieve capabilities ook als ze in HTML, XSLT, CSS of
> JavaScript getriggered worden daar niet wenselijk zijn en met een goede
> reden niet default aan staan.
Dat heeft weinig tot niks met media queries te maken, die zijn bedoeld voor
het aanpassen van vormgeving op basis van bepaalde criteria.
> Hoe vet het voor een developer ook kan zijn om met een trucje hardware
> acceleratie te gebruiken, als daarvoor een extra GPU aangezet moet worden
> en de accu sneller leeg raakt is het de vraag of dat de juiste manier is
> om met mobile om te gaan.
Over het algemeen zijn hardware-accelerated acties op mobiele apparaten een
stuk zuiniger dan wanneer ze op de CPU moeten draaien.
> Vroeger, toen er nog maar 1 type iPhone bestond leek het even te werken,
> nu begint het allemaal redelijk door de mand te vallen:
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
Mwa, volgens mij valt dat 'probleem' prima op te lossen als je je niet
blind gaat staren op het willen detecteren van ￜￜn type apparaat.
--
robert
>> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
>> wat beperktere real estate op schermgebied, niet onder voor z'n
>> desktop-broers.
>
> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
> mobile device zorgen er echt wel voor dat de mogelijkheden van een
> desktop browser van een orde groter zijn.
Ik heb het over de browser, niet over het apparaat waarop je die browser
>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
>> wat beperktere real estate op schermgebied, niet onder voor z'n
>> desktop-broers.
>
> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
> mobile device zorgen er echt wel voor dat de mogelijkheden van een
> desktop browser van een orde groter zijn.
draait.
> Dan gaat het er niet over dat Flash op mobile niet handig is, maar dat
> CPU en geheugen intensieve capabilities ook als ze in HTML, XSLT, CSS of
> JavaScript getriggered worden daar niet wenselijk zijn en met een goede
> reden niet default aan staan.
het aanpassen van vormgeving op basis van bepaalde criteria.
> Hoe vet het voor een developer ook kan zijn om met een trucje hardware
> acceleratie te gebruiken, als daarvoor een extra GPU aangezet moet worden
> en de accu sneller leeg raakt is het de vraag of dat de juiste manier is
> om met mobile om te gaan.
stuk zuiniger dan wanneer ze op de CPU moeten draaien.
> Vroeger, toen er nog maar 1 type iPhone bestond leek het even te werken,
> nu begint het allemaal redelijk door de mand te vallen:
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
blind gaat staren op het willen detecteren van ￜￜn type apparaat.
--
robert
Rob
Dec 28, 2012, 3:21:37 PM12/28/12
to
Roland van Ipenburg <roland.va...@xs4all.nl> wrote:
> Vroeger, toen er nog maar 1 type iPhone bestond leek het
> even te werken, nu begint het allemaal redelijk door de mand
> te vallen:
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
Ja precies. Daar zie je dat men kennelijk op zoek is naar een DPI
> even te werken, nu begint het allemaal redelijk door de mand
> te vallen:
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
value, maar de browser kan alleen selecteren op een PIXELS value.
Nou ik kan het nog sterker vertellen: eigenlijk ben ik op zoek naar
een SIZE value. Het interesseert me niet zo hoeveel pixels er zijn,
maar ik wil op een "klein scherm" gewoon wat dingen weglaten zoals een
groot company logo, een ondersteunende foto, een "mooie rand",
dat soort dingen. Omdat ik de gebruiker gewoon zo veel mogelijk plek
wil geven om de tekst te lezen.
Afijn dat is me prima gelukt met een stylesheet wat een aantal divs
display: none maakt en een aantal vast gelayoute tabellen op auto zet.
Op zich functioneert dat prima.
Waar het "fout" gaat is in het koppelen van dat stylesheet aan
devices met kleine schermpjes. Vooral omdat die devices niet willen
vertellen dat ze een klein schermpje hebben.
Hoe makkelijk zou het zijn als er gewoon een media type was wat zonder
schroom door mobieltjes kon worden herkend. Als "handheld" dan kennelijk
een besmette term is, waarom maken ze dan niet gewoon een nieuwe?
"mobile", "smartphone", "tablet", er is zo veel te bedenken.
Het is toch niet dat die namespace op de een of andere manier klein
gehouden moet worden ofzo?
Of anders een device-width attribuut wat in centimeters of inches is?
Roland van Ipenburg
Dec 28, 2012, 3:41:05 PM12/28/12
to
On 28 Dec 2012 20:03:18 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
het apparaat waar die browser op draait te maken?
> Roland van Ipenburg <roland.va...@xs4all.nl>:
>> On 28 Dec 2012 17:43:19 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>> mentioned:
>>
>>> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
>>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
>>> wat beperktere real estate op schermgebied, niet onder voor z'n
>>> desktop-broers.
>>
>> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
>> mobile device zorgen er echt wel voor dat de mogelijkheden van een
>> desktop browser van een orde groter zijn.
>
> Ik heb het over de browser, niet over het apparaat waarop je die browser
> draait.
Want de beperkte real estate op schermgebied heeft niets met
>> On 28 Dec 2012 17:43:19 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>> mentioned:
>>
>>> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
>>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van de
>>> wat beperktere real estate op schermgebied, niet onder voor z'n
>>> desktop-broers.
>>
>> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
>> mobile device zorgen er echt wel voor dat de mogelijkheden van een
>> desktop browser van een orde groter zijn.
>
> Ik heb het over de browser, niet over het apparaat waarop je die browser
> draait.
het apparaat waar die browser op draait te maken?
Roland van Ipenburg
Dec 28, 2012, 4:55:23 PM12/28/12
to
On 28 Dec 2012 20:21:37 GMT, Rob <nom...@example.com> mentioned:
ondersteunen, maar de iOS devices van Apple zijn er
natuurlijk vooral voor om geld te verdienen met de verkoop
van Apps via de AppStore, en daar zitten al zoveel voor de
10" iPad vastgetimmerde legacy Apps in dat het Apple niet
erg helpt wanneer webapps wel goed rekening zouden kunnen
houden met 19% verschil in grootte terwijl op hetzelfde
apparaat alle native Apps dan 19% te klein lijken. Apple
gaat er kennelijk van uit dat het voor de gebruikers die
kiezen voor de iPad mini geen probleem is dat alles 19%
kleiner is en dat het voor die gebruikservaring belangrijker
is dat native en web hetzelfde schalen dan dat web net zo
leesbaar zou zijn als op een gewone iPad. Daar zouden ze
best eens een punt kunnen hebben, en zelfs al zou je site
als één van de weinigen wel een hack gebruiken om daar van
af te wijken is het de vraag of de iPad mini gebruiker het
dan toch niet opeens te groot vind. Daarom laat ik sites ook
altijd door testers op hun eigen device testen omdat je
anders als snel bezig bent om een voor dat device
acceptabele ervaring om zeep te helpen in een poging het op
jouw ervaring met je eigen devices te laten lijken.
…
> Waar het "fout" gaat is in het koppelen van dat stylesheet aan
> devices met kleine schermpjes. Vooral omdat die devices niet willen
> vertellen dat ze een klein schermpje hebben.
Dat lijkt mij voornamelijk omdat de gebruikers ook niet in
hun browser kunnen of willen configureren wat ze klein
vinden. Hetzelfde device kan in princiepe door
verschillende gebruikers met verschillende diktes van
vingers en slechtheid van ogen anders ingesteld worden zodat
"klein" niet alleen maar afhankelijk is van de hardware en
meestal niet meer is dan een educated guess van een vendor
die in eerste instantie devices wil verkopen die werken met
het overgrote deel van de sites die er op dat moment zijn en
minder geïnteresseerd is in wat er daarna misschien nog
gebeurt.
> Hoe makkelijk zou het zijn als er gewoon een media type was wat zonder
> schroom door mobieltjes kon worden herkend. Als "handheld" dan kennelijk
> een besmette term is, waarom maken ze dan niet gewoon een nieuwe?
> "mobile", "smartphone", "tablet", er is zo veel te bedenken.
> Het is toch niet dat die namespace op de een of andere manier klein
> gehouden moet worden ofzo?
Nee, maar tussen de tijd dat het bedacht wordt en dat het
geïmplementeerd is kan wat er onder die term verstaan wordt
al weer helemaal anders zijn. Een smartphone uit 2002 is
iets heel anders dan een smartphone uit 2012.
> Of anders een device-width attribuut wat in centimeters of inches is?
Ik heb geen idee of bijvoorbeeld een HDMI apparaat dat te
weten kan komen van een aangesloten ander HDMI apparaat.
Want je wilt natuurlijk wel dat als je je 4" mobile device
thuis op je 40" TV aansluit de correcte device-width in
inches wordt gebruikt.
> Roland van Ipenburg <roland.va...@xs4all.nl> wrote:
>> Vroeger, toen er nog maar 1 type iPhone bestond leek het
>> even te werken, nu begint het allemaal redelijk door de mand
>> te vallen:
>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
>
> Ja precies. Daar zie je dat men kennelijk op zoek is naar een DPI
> value, maar de browser kan alleen selecteren op een PIXELS value.
IMHO zou Apple best een bruikbare media query kunnen
>> Vroeger, toen er nog maar 1 type iPhone bestond leek het
>> even te werken, nu begint het allemaal redelijk door de mand
>> te vallen:
>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
>
> Ja precies. Daar zie je dat men kennelijk op zoek is naar een DPI
> value, maar de browser kan alleen selecteren op een PIXELS value.
ondersteunen, maar de iOS devices van Apple zijn er
natuurlijk vooral voor om geld te verdienen met de verkoop
van Apps via de AppStore, en daar zitten al zoveel voor de
10" iPad vastgetimmerde legacy Apps in dat het Apple niet
erg helpt wanneer webapps wel goed rekening zouden kunnen
houden met 19% verschil in grootte terwijl op hetzelfde
apparaat alle native Apps dan 19% te klein lijken. Apple
gaat er kennelijk van uit dat het voor de gebruikers die
kiezen voor de iPad mini geen probleem is dat alles 19%
kleiner is en dat het voor die gebruikservaring belangrijker
is dat native en web hetzelfde schalen dan dat web net zo
leesbaar zou zijn als op een gewone iPad. Daar zouden ze
best eens een punt kunnen hebben, en zelfs al zou je site
als één van de weinigen wel een hack gebruiken om daar van
af te wijken is het de vraag of de iPad mini gebruiker het
dan toch niet opeens te groot vind. Daarom laat ik sites ook
altijd door testers op hun eigen device testen omdat je
anders als snel bezig bent om een voor dat device
acceptabele ervaring om zeep te helpen in een poging het op
jouw ervaring met je eigen devices te laten lijken.
…
> Waar het "fout" gaat is in het koppelen van dat stylesheet aan
> devices met kleine schermpjes. Vooral omdat die devices niet willen
> vertellen dat ze een klein schermpje hebben.
hun browser kunnen of willen configureren wat ze klein
vinden. Hetzelfde device kan in princiepe door
verschillende gebruikers met verschillende diktes van
vingers en slechtheid van ogen anders ingesteld worden zodat
"klein" niet alleen maar afhankelijk is van de hardware en
meestal niet meer is dan een educated guess van een vendor
die in eerste instantie devices wil verkopen die werken met
het overgrote deel van de sites die er op dat moment zijn en
minder geïnteresseerd is in wat er daarna misschien nog
gebeurt.
> Hoe makkelijk zou het zijn als er gewoon een media type was wat zonder
> schroom door mobieltjes kon worden herkend. Als "handheld" dan kennelijk
> een besmette term is, waarom maken ze dan niet gewoon een nieuwe?
> "mobile", "smartphone", "tablet", er is zo veel te bedenken.
> Het is toch niet dat die namespace op de een of andere manier klein
> gehouden moet worden ofzo?
geïmplementeerd is kan wat er onder die term verstaan wordt
al weer helemaal anders zijn. Een smartphone uit 2002 is
iets heel anders dan een smartphone uit 2012.
> Of anders een device-width attribuut wat in centimeters of inches is?
weten kan komen van een aangesloten ander HDMI apparaat.
Want je wilt natuurlijk wel dat als je je 4" mobile device
thuis op je 40" TV aansluit de correcte device-width in
inches wordt gebruikt.
Rob
Dec 28, 2012, 6:09:21 PM12/28/12
to
hun maat door aan het systeem waarop ze zijn aangesloten. Ik
kan dat hier met mijn nvidia control panel zo uitlezen voor de
monitoren die ik heb.
Roland van Ipenburg
Dec 28, 2012, 6:31:13 PM12/28/12
to
On 28 Dec 2012 23:09:21 GMT, Rob <nom...@example.com> mentioned:
Zou ook wel mooi zijn als een beamer dynamisch de grootte
van de projectie doorgeeft en je dan een element in
centimeters even groot zou kunnen houden of op die manier
responsive kan doen zodat je site niet groter wordt als je
de beamer verder van het projectiescherm zet ;-)
van de projectie doorgeeft en je dan een element in
centimeters even groot zou kunnen houden of op die manier
responsive kan doen zodat je site niet groter wordt als je
de beamer verder van het projectiescherm zet ;-)
robert
Dec 29, 2012, 12:26:08 AM12/29/12
to
Roland van Ipenburg <roland.va...@xs4all.nl>:
> On 28 Dec 2012 20:03:18 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>> Roland van Ipenburg <roland.va...@xs4all.nl>:
>>> On 28 Dec 2012 17:43:19 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>>> mentioned:
>>>
>>>> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
>>>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van
>>>> de wat beperktere real estate op schermgebied, niet onder voor z'n
>>>> desktop-broers.
>>>
>>> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
>>> mobile device zorgen er echt wel voor dat de mogelijkheden van een
>>> desktop browser van een orde groter zijn.
>>
>> Ik heb het over de browser, niet over het apparaat waarop je die browser
>> draait.
>
> Want de beperkte real estate op schermgebied heeft niets met het apparaat
> waar die browser op draait te maken?
Een mobiele browser heeft (over het algemeen) minder schermruimte tot z'n
> On 28 Dec 2012 20:03:18 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>> Roland van Ipenburg <roland.va...@xs4all.nl>:
>>> On 28 Dec 2012 17:43:19 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
>>> mentioned:
>>>
>>>> Tja, dat is volgens mij ooit bedoeld voor devices met zwaar beperkte
>>>> capabilities. Een mobiele browser van tegenwoordig doet, afgezien van
>>>> de wat beperktere real estate op schermgebied, niet onder voor z'n
>>>> desktop-broers.
>>>
>>> Was het maar waar. Het relatief kleine geheugen en de trage CPU van een
>>> mobile device zorgen er echt wel voor dat de mogelijkheden van een
>>> desktop browser van een orde groter zijn.
>>
>> Ik heb het over de browser, niet over het apparaat waarop je die browser
>> draait.
>
> Want de beperkte real estate op schermgebied heeft niets met het apparaat
> waar die browser op draait te maken?
beschikking dan een desktopbrowser, maar dat maakt de mobiele browser qua
browsercapabilities niet beperkter. De sites die je ervoor wilt ontwikkelen
wel, maar dat is iets anders.
--
robert
Roland van Ipenburg
Dec 29, 2012, 5:28:33 AM12/29/12
to
On 29 Dec 2012 05:26:08 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
Ik krijg eerder de indruk dat jouw capabilities zo beperkt
zijn dat je het verschil tussen een desktop browser en een
mobiele browser nog nooit bent tegengekomen.
zijn dat je het verschil tussen een desktop browser en een
mobiele browser nog nooit bent tegengekomen.
robert
Dec 29, 2012, 8:05:45 AM12/29/12
to
Roland van Ipenburg <roland.va...@xs4all.nl>:
> On 29 Dec 2012 05:26:08 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>>
> On 29 Dec 2012 05:26:08 GMT, robert <US3N37+{n.i.w.o}@gmail.com>
> mentioned:
>>
>> Een mobiele browser heeft (over het algemeen) minder schermruimte tot
>> z'n beschikking dan een desktopbrowser, maar dat maakt de mobiele
>> browser qua browsercapabilities niet beperkter. De sites die je ervoor
>> wilt ontwikkelen wel, maar dat is iets anders.
>
> Ik krijg eerder de indruk dat jouw capabilities zo beperkt zijn...
>> z'n beschikking dan een desktopbrowser, maar dat maakt de mobiele
>> browser qua browsercapabilities niet beperkter. De sites die je ervoor
>> wilt ontwikkelen wel, maar dat is iets anders.
>
Heuh, lekker jijbakken als je je gelijk niet krijgt! Doei Roland.
--
robert
Roland van Ipenburg
Dec 29, 2012, 8:47:28 AM12/29/12
to
On 29 Dec 2012 13:05:45 GMT, robert <US3N37+{n.i.w.o}@gmail.com> mentioned:
De enige manier waarop jij met jouw redenatie nog gelijk zou
kunnen krijgen is met een nogal abstracte definitie van
"mobiele browser" die op ieder Turing compleet systeem in
theorie precies zou kunnen doen wat jij wilt, ondertussen
alles negerend wat in de praktijk de uitdagingen van wat
normaal als mobiele browser beschouwd wordt zijn. Volgens
jou kan de browser alles en worden alle beperkingen
veroorzaakt door hardware, firmware, OS, drivers en
libraries waar die browser op een bepaald device van
afhankelijk is, maar dat is dan iets anders. En dan vind je
het raar dat ik concludeer dat jouw definitie van klok dus
geen klepel heeft?
kunnen krijgen is met een nogal abstracte definitie van
"mobiele browser" die op ieder Turing compleet systeem in
theorie precies zou kunnen doen wat jij wilt, ondertussen
alles negerend wat in de praktijk de uitdagingen van wat
normaal als mobiele browser beschouwd wordt zijn. Volgens
jou kan de browser alles en worden alle beperkingen
veroorzaakt door hardware, firmware, OS, drivers en
libraries waar die browser op een bepaald device van
afhankelijk is, maar dat is dan iets anders. En dan vind je
het raar dat ik concludeer dat jouw definitie van klok dus
geen klepel heeft?
Roland van Ipenburg
Dec 30, 2012, 11:46:28 AM12/30/12
to
On 29 Dec 2012 13:47:28 GMT, Roland van Ipenburg <roland.va...@xs4all.nl> mentioned:
Een voorbeeld uit de praktijk is dat sommige devices een met
CSS gedefinieerde linear gradient met lelijke banding
weergeven. Dan kan het best zijn dat de browser de juiste
call naar een API daarvoor doet en die layer daarop dat ook
weer helemaal goed doet, etc., maar uiteindelijk ziet de
eindgebruiker lelijke banding. Als je dat dan wil oplossen
door met een media query de color depth te checken en bij te
weinig depth een pre-dithered image als fallback te
gebruiken blijkt die browser toch gewoon full color terug te
geven terwijl dat dus niet zo is. Dan kan het ook weer zijn
dat de browser die waarde op de juiste manier van de
onderliggende laag opvraagt maar een verkeerde waarde
daarvan terugkrijgt en de browser volgens jou niets verkeert
doet. Maar als de maker van de browser ondertussen wel weet
dat alles waar zijn zogenaamde capabilities op gebaseerd
zijn dus onbruikbaar is, dan wordt de browser bewust beperkt
gemaakt door niet voor een andere oplossing te kiezen,
bijvoorbeeld door na het installeren een aantal calibratie
stappen te doorlopen zodat een gebruiker onafhankelijk van
liegende APIs aan kan geven wat er in werkelijkheid aan de
hand is. Dat is misschien geen oplossing die jij zou kunnen
bedenken, maar dat maakt het niet iets anders dan een issue
met de browser.
CSS gedefinieerde linear gradient met lelijke banding
weergeven. Dan kan het best zijn dat de browser de juiste
call naar een API daarvoor doet en die layer daarop dat ook
weer helemaal goed doet, etc., maar uiteindelijk ziet de
eindgebruiker lelijke banding. Als je dat dan wil oplossen
door met een media query de color depth te checken en bij te
weinig depth een pre-dithered image als fallback te
gebruiken blijkt die browser toch gewoon full color terug te
geven terwijl dat dus niet zo is. Dan kan het ook weer zijn
dat de browser die waarde op de juiste manier van de
onderliggende laag opvraagt maar een verkeerde waarde
daarvan terugkrijgt en de browser volgens jou niets verkeert
doet. Maar als de maker van de browser ondertussen wel weet
dat alles waar zijn zogenaamde capabilities op gebaseerd
zijn dus onbruikbaar is, dan wordt de browser bewust beperkt
gemaakt door niet voor een andere oplossing te kiezen,
bijvoorbeeld door na het installeren een aantal calibratie
stappen te doorlopen zodat een gebruiker onafhankelijk van
liegende APIs aan kan geven wat er in werkelijkheid aan de
hand is. Dat is misschien geen oplossing die jij zou kunnen
bedenken, maar dat maakt het niet iets anders dan een issue
met de browser.
0 new messages