🚀 go-pugleaf

P.S.
Wyjaśnię, że początkowo dążyłem do tego aby m.in. na podstawie PPI 
wykrywać z jakim urządzeniem mam do czynienia i na tej podstawie 
dostarczać odpowiedni CSS. Czyli w uproszczeniu mała rozdzielczość -> 
monitor, duża rozdzielczość -> urządzenie przenośne, potrzeba 
dostarczenia ortopedycznych buttonów. Niestety ta najłatwiejsza metoda 
detekcji nie działa i szczerze mówiąc nie wiem jak sobie poradzić.

W dniu 2016-05-15 o 21:19, Marek pisze:
> Czy ktoś z Was jest w stanie wytłumaczyć mi jak działają piksele na
> urządzeniach mobilnych? Póki co wszelkie moje starania w kierunku
> rozszyfrowania jednostek spełzły na niczym. Przygotowałem kod testowy:

(...)

> Czytałem w sieci na ten temat jednakże zwykle trafiałem na dywagacje
> metafizyczne. Nic z tego nie rozumiem.

A to:

https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
(w treści jest też odnośnik do tego:
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html)

Chyba dość stary artykuł, ale zakładam że nadal aktualny.
Po szybkim przeczytaniu wygląda na całkiem proste wytłumaczenie, z 
wnioskiem, że pixele na urządzeniach mobilnych działają różnie w 
zależności od urządzenia, i że pixele css to nie te same pixele co na 
urządzeniu :)

Nie miałem do tej pory potrzeby walki z urządzeniami mobilnymi, 
poszukałem z ciekawości, a ten opis wydaje mi się wystarczający do 
zrozumienia o co chodzi.

Pozdrawiam
Piotr

W dniu 16.05.2016 o 01:11, Kviat pisze:
> W dniu 2016-05-15 o 21:19, Marek pisze:

> A to:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
> (w treści jest też odnośnik do tego:

Hej.

Dokładnie ten artykuł czytałem. W wujku Google pojawia się ona jako #1. 
Mogę się zgodzić, że 1 piksel CSS może zająć 4 czy 8 czy ... pikseli 
urządzenia. Kłopot w tym, że cal ma zawsze 96 pikseli i nigdy nie ma 
rozmiaru cala - więc teoria się wali. Oczywiście w szczególności na 
monitorze o rozdzielczości 96dpi cal będzie calem.

Po drugie, skoro HTML nie dostaje informacji o rozdzielczości matrycy (w 
dpi) to jak się ustala czy mamy użyć CSS jak dla komórek czy jak dla 
tabletów czy jak dla desktopów? Nie wyobrażam sobie procesu detekcji na 
podstawie sprawdzania w bazie danych nazwy przeglądarki / systemu 
operacyjnego i na tej podstawie domniemanie czy to urządzenie należy do 
danej grupy.

-- 
Pozdrawiam,
Marek

Dnia Mon, 16 May 2016 21:14:14 +0200, Marek napisał(a):

> Po drugie, skoro HTML nie dostaje informacji o rozdzielczości matrycy (w 
> dpi) to jak się ustala czy mamy użyć CSS jak dla komórek czy jak dla 
> tabletów czy jak dla desktopów? Nie wyobrażam sobie procesu detekcji na 
> podstawie sprawdzania w bazie danych nazwy przeglądarki / systemu 
> operacyjnego i na tej podstawie domniemanie czy to urządzenie należy do 
> danej grupy.

Rozmiar ekranu wykrywasz za pomocą media queries, określając granice od
których mają obowiązywać inne style. To jest podstawa RWD.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 16.05.2016 o 21:25, Borys Pogoreło pisze:
>
> Rozmiar ekranu wykrywasz za pomocą media queries, określając granice od
> których mają obowiązywać inne style. To jest podstawa RWD.
>

No ale jak? Np. resolution ma nieprawdziwe dane. Wymiary CSS ekranów też 
są z palca wyssane i mogą podawać. U mnie szerokość ekranu to ponoć 
419px (przy 1440px fizycznych). Na jakimś szajsfonie widziałem 320px. 
Cale w media queries podają również dziwaczne wartości.

-- 
Pozdrawiam,
Marek

Dnia Tue, 17 May 2016 19:11:37 +0200, Marek napisał(a):

> No ale jak? Np. resolution ma nieprawdziwe dane. Wymiary CSS ekranów też 
> są z palca wyssane i mogą podawać. U mnie szerokość ekranu to ponoć 
> 419px (przy 1440px fizycznych). Na jakimś szajsfonie widziałem 320px. 
> Cale w media queries podają również dziwaczne wartości.

Nie licz na to, że ustawisz to sobie co do piksela. Tu chodzi tylko o
zakresy, w jakich pewne elementy przestają być czytelne i trzeba zmienić
ich układ. Zamiast pikseli możesz granice określać po prostu w em, wtedy
zależą od wielkości tekstu, co wydaje się najsensowniejszym podejściem.
Frameworki najczęściej zakładają trzy zakresy - do 768px (telefon), do
1024px (tablet) i powyżej (desktop). Nie zawsze odpowiada to prawdzie, ale
wystarcza. Tu chodzi o czytelnosć, a nie dostosowanie do konkretnego
urządzenia.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 17.05.2016 o 21:53, Borys Pogoreło pisze:

> Nie licz na to, że ustawisz to sobie co do piksela.

Wiesz, pal sześć dokładność co do piksela. Nie w tym rzecz. Urządzenie, 
które ma 1440px w poziomie w prortrait jest raportowane jako 419px 
(Nexus 6). Nie da się wyliczyć rozdzielczości urządzenia w DPI choćby z 
tego względu. Wydaje mi się, że DPI jest najlepszą jednostką do 
określania jak duże litery na danym urządzeniu powinno się wyświetlać. 
Zupełnie nie rozumiem czemu zafałszowano tą informację w urządzeniach 
mimo istnienia parametru resolution w media query.

Aczkolwiek może jest obejście jak piszesz poniżej.

> Tu chodzi tylko o
> zakresy, w jakich pewne elementy przestają być czytelne i trzeba zmienić
> ich układ. Zamiast pikseli możesz granice określać po prostu w em, wtedy
> zależą od wielkości tekstu, co wydaje się najsensowniejszym podejściem.

W zasadzie racja. Mam nadzieję, że em nie będą zafałszowane na jakiś 
urządzeniach mobilnych tak jak z pikselami ma to miejsce, które mają się 
nijak do rzeczywistości. Przebadam to ale optymistą nie jestem.

> Frameworki najczęściej zakładają trzy zakresy - do 768px (telefon), do
> 1024px (tablet) i powyżej (desktop). Nie zawsze odpowiada to prawdzie, ale
> wystarcza. Tu chodzi o czytelnosć, a nie dostosowanie do konkretnego
> urządzenia.

I najciekawsze jest to, że tylko dla desktopu piksele są prawdziwe, 
zgodne z wielkością okna przeglądarki a w pozostałych przypadkach - 
losowe - być może w pewnym zakresie tylko. Zapewne webmasterzy już 
wypraktykowali te zakresy pikseli podawanych przez mobilne więc chyba to 
w miarę dobre kryteria.

-- 
Pozdrawiam,
Marek

Dnia Thu, 19 May 2016 11:58:58 +0200, Marek napisał(a):

> Wiesz, pal sześć dokładność co do piksela. Nie w tym rzecz. Urządzenie, 
> które ma 1440px w poziomie w prortrait jest raportowane jako 419px 
> (Nexus 6). Nie da się wyliczyć rozdzielczości urządzenia w DPI choćby z 
> tego względu. Wydaje mi się, że DPI jest najlepszą jednostką do 
> określania jak duże litery na danym urządzeniu powinno się wyświetlać. 
> Zupełnie nie rozumiem czemu zafałszowano tą informację w urządzeniach 
> mimo istnienia parametru resolution w media query.

Bo jakbyś poza wielkością ekranów jeszcze musiał walczyć z różnymi
rozdzielczościami, to już nikt by się w tym nie odnalazł. Dlatego wymyślono
rozdzielczość logiczną w CSS, żeby to jakoś ujednolicić.

> I najciekawsze jest to, że tylko dla desktopu piksele są prawdziwe, 
> zgodne z wielkością okna przeglądarki a w pozostałych przypadkach - 
> losowe - być może w pewnym zakresie tylko. 

A masz włączone skalowanie DPI w systemie?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 19.05.2016 o 17:48, Borys Pogoreło pisze:

> Bo jakbyś poza wielkością ekranów jeszcze musiał walczyć z różnymi
> rozdzielczościami, to już nikt by się w tym nie odnalazł. Dlatego wymyślono
> rozdzielczość logiczną w CSS, żeby to jakoś ujednolicić.

Hmmm... niekoniecznie tak. Jeśli miałbym podane dpi ekranu to 
jednoznacznie wiedziałbym, że aby czcionka była czytelna, to musi mieć X 
pikseli. Np. przy ekranie 96 dpi czcionka 12px będzie wyglądała tak samo 
jak na urządzeniu mobilnym o 180 dpi przy 24px. Przelicznik jest 
banalnie prosty. Nie muszę dbać o fizyczne rozmiary urządzenia.

Oczywiście zakładam, że nie powstaną jakieś absurdalne wyświetlacze o 
szerokości piksela, gdzie niczego nie wyświetlisz.

Ponadto to ujednolicenie jest dość słabe kiedy niemalże ta sama 
rozdzielczość dpi na iPhonie to 320px a na jakimś Androidzie 419px.

Po trzecie, wprowadzono do media queries parametr resolution, który 
poprzez to ujednolicenie storpedowano.

> A masz włączone skalowanie DPI w systemie?

Ja nie o tym mówię. W desktopach rozmiar pixelowy przeglądarki jest 1:1 
przekazywany. Zarówno CSS jak i JS "wiedzą" ile dokładnie mamy px. 
Możemy zatem budować media w oparciu o zakresy pixelowe bardzo 
precyzyjnie. W mobilnych px nie jest px lecz abstrakcyjną jednostką, w 
dodatku różną w różnych urządzeniach. No i o tym mówię.

A co do Twojej intencji w/w pytania (zapewne miałeś na myśli poprawne 
wyświetlanie wymiarów calowych): akurat ja nie muszę gdyż mój monitor ma 
dokładnie 96dpi. A czy to nie działa w drugą stronę? Driver monitora 
przekazuje systemowi rozdzielczość w px i dpi, driver karty ustawioną 
rozdzielczość px i na tej podstawie wyliczana jest fizyczna 
rozdzielczość dpi dostarczana do przeglądarek? Nie sprawdzałem ale test 
jest ciekawy. Zweryfikuję.

-- 
Pozdrawiam,
Marek

Użytkownik "Marek" <precz@spamowi.com> napisał w wiadomości 
news:nhmi4u$85p$1@news.icm.edu.pl...
>W dniu 19.05.2016 o 17:48, Borys Pogoreło pisze:
>
>> Bo jakbyś poza wielkością ekranów jeszcze musiał walczyć z różnymi
>> rozdzielczościami, to już nikt by się w tym nie odnalazł. Dlatego 
>> wymyślono
>> rozdzielczość logiczną w CSS, żeby to jakoś ujednolicić.
>
> Hmmm... niekoniecznie tak. Jeśli miałbym podane dpi ekranu to 
> jednoznacznie wiedziałbym, że aby czcionka była czytelna, to musi mieć X 
> pikseli. Np. przy ekranie 96 dpi czcionka 12px będzie wyglądała tak samo 
> jak na urządzeniu mobilnym o 180 dpi przy 24px. Przelicznik jest banalnie 
> prosty. Nie muszę dbać o fizyczne rozmiary urządzenia.

Chyba za mocno kombiunujesz.
Ci co używają np bootstrapa po prostu używaja i nie zastanawiają się jak to 
działa.

Pod Androidem jest tak że dla 160dpi 1px fizyczny = 1px logiczny.

Każdy telefon ma swój przelicznik: 1x, 1.5x, 2x, 2.5x, 3x itd (zaokrąglane 
do 0.5)
(jak ktos troche programował pod Androida to wie o co chodzi)

Jak dasz na stronie czcionke 12px to z grubsza na każdym telefonie czy 
tablecie
będzie wyglądało podobnie - przeglądarka sama to przeskaluje do fizycznych 
np 48px (na telefonie o dużej gęstości 4x)

Dnia Fri, 20 May 2016 10:33:24 +0200, Marek napisał(a):

> Hmmm... niekoniecznie tak. Jeśli miałbym podane dpi ekranu to 
> jednoznacznie wiedziałbym, że aby czcionka była czytelna, to musi mieć X 
> pikseli. Np. przy ekranie 96 dpi czcionka 12px będzie wyglądała tak samo 
> jak na urządzeniu mobilnym o 180 dpi przy 24px. Przelicznik jest 
> banalnie prosty. Nie muszę dbać o fizyczne rozmiary urządzenia.

A teraz piszesz po prostu "12px" i wiesz +/- jakiej wielkości będzie
czcionka, więc jaka to różnica? Reszta to zmartwienie przeglądarki.

> Ponadto to ujednolicenie jest dość słabe kiedy niemalże ta sama 
> rozdzielczość dpi na iPhonie to 320px a na jakimś Androidzie 419px.

I co by się zmieniło, gdybyś miał dokładne wymiary ekranu? Wyświetlasz
stronę internetową, a nie rysunki CAD. To nie to medium.

> Ja nie o tym mówię. W desktopach rozmiar pixelowy przeglądarki jest 1:1 
> przekazywany. Zarówno CSS jak i JS "wiedzą" ile dokładnie mamy px. 
> Możemy zatem budować media w oparciu o zakresy pixelowe bardzo 
> precyzyjnie. W mobilnych px nie jest px lecz abstrakcyjną jednostką, w 
> dodatku różną w różnych urządzeniach. No i o tym mówię.

Chciałbyś, żeby było tak prosto. Na Retinie też masz inne piksele w CSS,
niż fizyczne.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2016-05-20 o 18:36, Borys Pogoreło pisze:
> I co by się zmieniło, gdybyś miał dokładne wymiary ekranu? Wyświetlasz
> stronę internetową, a nie rysunki CAD. To nie to medium.

No jak nie jak tak ;)

https://play.google.com/store/apps/details?id=com.autodesk.autocadws

Pozdrawiam
Piotr

Dnia Fri, 20 May 2016 22:18:01 +0200, Kviat napisał(a):

>> I co by się zmieniło, gdybyś miał dokładne wymiary ekranu? Wyświetlasz
>> stronę internetową, a nie rysunki CAD. To nie to medium.
> 
> No jak nie jak tak ;)
> https://play.google.com/store/apps/details?id=com.autodesk.autocadws

Ale to jest natywna apka, a tam masz więcej jednostek do dyspozycji niż w
CSS. Podejrzewam też, że tamtejsze np. milimetry odpowiadają prawdzie
(przynajmniej tak wynika z tabelek, do których właśnie zajrzałem). Pisząc o
medium miałem na myśli to, że dla strony internetowej fizyczne centymetry
nie maja większego znaczenia.

W przeglądarkach cyrk był zawsze i będzie, ja sie przyzwyczaiłem. Marek
dopiero odkrywa nowe obszary tego bałaganu ;)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2016-05-20 o 22:46, Borys Pogoreło pisze:
> Dnia Fri, 20 May 2016 22:18:01 +0200, Kviat napisał(a):
>
>>> I co by się zmieniło, gdybyś miał dokładne wymiary ekranu? Wyświetlasz
>>> stronę internetową, a nie rysunki CAD. To nie to medium.
>>
>> No jak nie jak tak ;)
>> https://play.google.com/store/apps/details?id=com.autodesk.autocadws
>
> Ale to jest natywna apka,

https://sharecad.org/pl
Przed chwilą dla testów wczytałem rysunek dwg i działa to całkiem sprawnie.

> a tam masz więcej jednostek do dyspozycji niż w
> CSS. Podejrzewam też, że tamtejsze np. milimetry odpowiadają prawdzie
> (przynajmniej tak wynika z tabelek, do których właśnie zajrzałem). Pisząc o
> medium miałem na myśli to, że dla strony internetowej fizyczne centymetry
> nie maja większego znaczenia.

To tak jak w CAD. W sensie wyświetlania rysunku na monitorze.
Rysunek w skali 1:1 (cali, mm, cm...) ma sens na papierze i tak się 
zastanawiałem dlaczego Marek potrzebuje wyświetlić kwadrat 1 cal x 1 cal 
na wyświetlaczu? User zrobi zoom i po zawodach...
Na dużym monitorze fajnie jest wyświetlić sobie kartkę A4 w skali 1:1 i 
zobaczyć przed wydrukiem jak to wygląda. Na małym wyświetlaczu też się 
da, ale zobaczy się tylko kawałek kartki... lub przeskaluje tak, aby się 
zmieściła na wyświetlaczu.
Więc istotne jest to, żeby to był kwadrat, a reszta to kwestia 
skalowania tylko. I oczywiście proporcji pozostałych elementów.

Może robi jakąś mobilną miarkę żeby zmierzyć długość sznurka 
przykładając go do wyświetlacza nie mając pod ręką linijki, a smartfona 
przecież każdy ma zawsze i wszędzie ;)

> W przeglądarkach cyrk był zawsze i będzie, ja sie przyzwyczaiłem. Marek
> dopiero odkrywa nowe obszary tego bałaganu ;)

Będzie trochę OT (i tak na grupie pusto), ale skoro już wspomniałeś o 
cadzie w kontekście przeglądarek...
Jakiś czas temu próbowałem się pobawić WebGL do wyświetlania projektów 
3D cad w przeglądarce, ale okazało się, że nie jest mi to aż tak bardzo 
potrzebne jak myślałem :) żeby tak dużo czasu marnować na pokonywanie 
takich dziwnych problemów. W niektórych urządzeniach działało, w 
niektórych tak sobie, łącznie z zawieszaniem przeglądarki. Może coś się 
poprawiło w tym temacie od tamtego czasu, nie śledziłem ostatnio.
Ludzie nawet całkiem fajne rzeczy w tym robią, np.
http://planetoweb.net/app/
http://www.webgl-publisher.com/MobileSample.html
Ale dopóki nie będę miał pewności, że to będzie chodzić tak jak oczekuję 
na każdej przeglądarce, to na razie pomysł czeka z realizacją na rozwój 
sytuacji :)

Pozdrawiam
Piotr

Dnia Sat, 21 May 2016 14:27:10 +0200, Kviat napisał(a):

>> Ale to jest natywna apka,
> 
> https://sharecad.org/pl
> Przed chwilą dla testów wczytałem rysunek dwg i działa to całkiem sprawnie.

A udało im się jakoś zrobić ten "cal fizyczny"? Na upartego można mieć bazę
urządzeń i skalować, w tak niszowych zastosowaniach to się może sprawdzić.

> To tak jak w CAD. W sensie wyświetlania rysunku na monitorze.
> Rysunek w skali 1:1 (cali, mm, cm...) ma sens na papierze i tak się 
> zastanawiałem dlaczego Marek potrzebuje wyświetlić kwadrat 1 cal x 1 cal 
> na wyświetlaczu? User zrobi zoom i po zawodach...

To mu się zablokuje ;)

> Ludzie nawet całkiem fajne rzeczy w tym robią, np.
> http://planetoweb.net/app/
> http://www.webgl-publisher.com/MobileSample.html

Oj, Firefox to mógłby popracować nad wydajnością dla bardziej
skomplikowanych modeli. "Flat" działa mi niczym na Rivie TNT. Chrome zasuwa
aż miło.

> Ale dopóki nie będę miał pewności, że to będzie chodzić tak jak oczekuję 
> na każdej przeglądarce, to na razie pomysł czeka z realizacją na rozwój 
> sytuacji :)

To akurat smutny webowy standard. Też się kiedyś pobawiłem, stwierdziłem
"fajna rzecz" i odłożyłem na półkę pod tytułem "może za 2-3 lata", tuż obok
przykładowo flexboksa czy SVG sprites. Choć w przypadku tych ostatnich
można zapewnić zgodnosć "w dół" przez odpowiednią ilość dodatkowej pracy, a
WebGL za bardzo nie da się zastąpić. Chyba, że jakimiś dziwnymi wynalazkami
typu Unity.

Tak swoją drogą trochę to dziwne. Przecież już z 20 lat temu zaczął się
popularyzować VRML i nagle wszystko umarło i jest odkrywane na nowo.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2016-05-22 o 00:46, Borys Pogoreło pisze:
> Dnia Sat, 21 May 2016 14:27:10 +0200, Kviat napisał(a):
>
>>> Ale to jest natywna apka,
>>
>> https://sharecad.org/pl
>> Przed chwilą dla testów wczytałem rysunek dwg i działa to całkiem sprawnie.
>
> A udało im się jakoś zrobić ten "cal fizyczny"? Na upartego można mieć bazę
> urządzeń i skalować, w tak niszowych zastosowaniach to się może sprawdzić.

W programach cad to proste.
Rysujesz kwadracik 1x1 (albo 10x10, albo 100x100 itd) (nie ważne czego, 
bo to zależy jaką jednostkę ustawisz sobie w programie). Przykładasz 
calową suwmiarkę do monitora, kręcisz kółkiem myszy i patrzysz czy się 
mieści w suwmiarce. Jak nie możesz wcelować, to zmieniasz skok zoomu na 
mniejszy.

:)


> To akurat smutny webowy standard. Też się kiedyś pobawiłem, stwierdziłem
> "fajna rzecz" i odłożyłem na półkę pod tytułem "może za 2-3 lata", tuż obok
> przykładowo flexboksa czy SVG sprites. Choć w przypadku tych ostatnich
> można zapewnić zgodnosć "w dół" przez odpowiednią ilość dodatkowej pracy, a
> WebGL za bardzo nie da się zastąpić. Chyba, że jakimiś dziwnymi wynalazkami
> typu Unity.

Otóż to. Raz na jakiś czas rzucę na to okiem, bo nigdy nie wiadomo kiedy 
dojrzeje do zastosowania w czymś poważniejszym niż edukacja (nie miałem 
na myśli, że edukacja jest nieważna :)).
Unity w kontekście weba w ogóle nie ruszałem, ale desktop do 
wizualizacji 3D projektów cada owszem - tym razem, dla mnie, to armata 
na muchę.

> Tak swoją drogą trochę to dziwne. Przecież już z 20 lat temu zaczął się
> popularyzować VRML i nagle wszystko umarło i jest odkrywane na nowo.

I jak właśnie czytam, przerodziło się w X3D... które jako rozszerzenie 
wydaje się mieć aspiracje do do konkurowania z WebGL.
Ciekawe jak to się skończy :) Stawiam orzechy przeciwko bananom, że w 
przeglądarkach również zwyciężą te rozwiązania, które będą wspierać 
sprzętowe możliwości kart graficznych.

Pozdrawiam.
Piotr

Dnia Mon, 23 May 2016 08:25:21 +0200, Kviat napisał(a):

> W programach cad to proste.
> Rysujesz kwadracik 1x1 (albo 10x10, albo 100x100 itd) (nie ważne czego, 
> bo to zależy jaką jednostkę ustawisz sobie w programie). Przykładasz 
> calową suwmiarkę do monitora, kręcisz kółkiem myszy i patrzysz czy się 
> mieści w suwmiarce. Jak nie możesz wcelować, to zmieniasz skok zoomu na 
> mniejszy.

No tak, ale to trzeba mieć suwmiarkę. Ja miałem nadzieję, że sami z siebie
ten "cal fizyczny" są w stanie wyświetlić.

> I jak właśnie czytam, przerodziło się w X3D... które jako rozszerzenie 
> wydaje się mieć aspiracje do do konkurowania z WebGL.
> Ciekawe jak to się skończy :) Stawiam orzechy przeciwko bananom, że w 
> przeglądarkach również zwyciężą te rozwiązania, które będą wspierać 
> sprzętowe możliwości kart graficznych.

Póki trzeba instalować jakieś dodatkowe wtyczki, to pewnie zbyt popularne
nie będzie. Jedna firma, zastosowanie niszowe... Nawet popularne wtyczki
umierają. A tu jeszcze zapowiedzieli jakieś Vulkan API, za którym stoi paru
dużych graczy.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2016-05-23 o 13:41, Borys Pogoreło pisze:
> Dnia Mon, 23 May 2016 08:25:21 +0200, Kviat napisał(a):
>
>> W programach cad to proste.
>> Rysujesz kwadracik 1x1 (albo 10x10, albo 100x100 itd) (nie ważne czego,
>> bo to zależy jaką jednostkę ustawisz sobie w programie). Przykładasz
>> calową suwmiarkę do monitora, kręcisz kółkiem myszy i patrzysz czy się
>> mieści w suwmiarce. Jak nie możesz wcelować, to zmieniasz skok zoomu na
>> mniejszy.
>
> No tak, ale to trzeba mieć suwmiarkę. Ja miałem nadzieję, że sami z siebie
> ten "cal fizyczny" są w stanie wyświetlić.

Heh :) Ja to w formie żartu napisałem. Nie są.

No prawie żartu, bo w zasadzie jaki miałby być sens wyświetlenia "cala 
fizycznego" na monitorze? To nigdy nie będzie dokładne (a w zasadzie to 
trzeba by było zapytać z jaką dokładnością ma być wyświetlony i te cale 
też są różne ;)

To sobie pożartujmy dalej...
Np. cal angielski = 25,3995 mm
(Na wiki znalazłem np. że: "Ponadto w USA jest jeszcze w użyciu 
amerykański cal geodezyjny ≈ 25,4000508 mm" - cóż za dokładność ;)

Wielkość piksela jest różna różnych monitorach czy matrycach, przyjmijmy 
że przykładowo piksel = 0,29375 (znalazłem na jakiejś stronie, pierwszej 
z brzegu).

Czyli kreska o długości jednego cala musiałaby mieć 86,46638298 
pixela... a tak się nie da :)
Lecimy w drugą stronę: 86 pixeli x 0,29375 = 25,2625 mm, hmmm,
może 87 pixeli x 0,29375 = 25,55625 mm
Bliżej 1 cala jest 86 pixeli... ale to akurat na tym, konkretnym 
monitorze i nadal to nie jest cal :)
Zaokrąglenie cala, czyli zmniejszenie dokładności, do 25,4 mm nadal nam 
nic nie daje, bo to ciągle ok. 86,5 pixela...
To samo dotyczy milimetra czy centymetra.

Koniec żartów.
W programach cad nie ma żadnego sensownego powodu wyświetlania na 
monitorze suwmiarki ;)
Stąd też moje pytanie, do czego Markowi potrzebny jest jednocalowy 
kwadrat na wyświetlaczu?

>> I jak właśnie czytam, przerodziło się w X3D... które jako rozszerzenie
>> wydaje się mieć aspiracje do do konkurowania z WebGL.
>> Ciekawe jak to się skończy :) Stawiam orzechy przeciwko bananom, że w
>> przeglądarkach również zwyciężą te rozwiązania, które będą wspierać
>> sprzętowe możliwości kart graficznych.
>
> Póki trzeba instalować jakieś dodatkowe wtyczki, to pewnie zbyt popularne
> nie będzie. Jedna firma, zastosowanie niszowe... Nawet popularne wtyczki
> umierają. A tu jeszcze zapowiedzieli jakieś Vulkan API, za którym stoi paru
> dużych graczy.

Wyświetlenie w przeglądarce prototypu obiektu 3D narysowanego w cadzie 
nie wymaga dokładności obrabiarki numerycznej, a że nie każdy ma pod 
ręką program cadowski (albo inny, który by rozumiał format cada), a 
przeglądarkę ma każdy, nawet w telefonie :), stąd zrodził się taki 
pomysł racjonalizatorski... pewnie za jakiś czas do niego wrócę :)

Pozdrawiam
Piotr

> Chyba za mocno kombiunujesz.

OK, chyba masz rację. Sklonuję więc podejście obowiązujące w sieci bez 
wnikania.


-- 
Pozdrawiam,
Marek

W dniu 20.05.2016 o 18:36, Borys Pogoreło pisze:

> A teraz piszesz po prostu "12px" i wiesz +/- jakiej wielkości będzie
> czcionka, więc jaka to różnica? Reszta to zmartwienie przeglądarki.

Ok, nie będę więc wnikał :-) Wydaje mi się to wszystko przekombinowane, 
niepotrzebnie utrudnione. Pomyślałem sobie, że gdybym znał dpi (zresztą 
taki parametr w media query istnieje i robi za atrapę), to mógłbym 
relatywnie dostosować wszystko co chcę. No ale cóż, mamy co mamy.


-- 
Pozdrawiam,
Marek

Dnia Mon, 23 May 2016 21:16:40 +0200, Marek napisał(a):

> Ok, nie będę więc wnikał :-) Wydaje mi się to wszystko przekombinowane, 
> niepotrzebnie utrudnione. Pomyślałem sobie, że gdybym znał dpi (zresztą 
> taki parametr w media query istnieje i robi za atrapę), to mógłbym 
> relatywnie dostosować wszystko co chcę. No ale cóż, mamy co mamy.

No ok, to załóżmy, że masz "294 dpi" - co z tym zrobisz?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 23.05.2016 o 23:41, Borys Pogoreło pisze:

>
> No ok, to załóżmy, że masz "294 dpi" - co z tym zrobisz?
>

Przepraszam za zwłokę. Byłem bardzo zajęty pracą.

Zrobiłbym tak (opisowo):

if media resolution<100dpi
font-size: 12px

else if media resolution<200dpi
font-size: 24px

else
font-size: 36px

To poglądowo, nie zastanawiałem się nad konkretnymi przedziałami 
precyzyjnie. Generalnie chodzi o to, że wielkość czcionki na różnych 
urządzeniach będzie podobna zgodnie ze skokiem rozdzielczości. Algorytm 
banalny, nie dbamy czy to pion czy poziom. Podobnie można postąpić z 
szerokością bloków na stronie.

-- 
Pozdrawiam,
Marek

W dniu 2016-05-15 o 21:19, Marek pisze:
> Czy ktoś z Was jest w stanie wytłumaczyć mi jak działają piksele na
> urządzeniach mobilnych? [...]

> div {
>      width: 1in;
>      height: 1in;
> }

O fizycznych jednostkach na ekranie lepiej zapomniec. Nie znam metody 
odtworzenia 1:1 fizycznego wymiaru na ekranie bez uprzedniej kalibracji 
monitora czy wyswietlacza. Serwisy, ktore prezentuja czy pozwalaja 
porownywac np telefony w skali naturalnej stosuja najczesciej 
nastepujaca metode kalibracji pocztas pierwszego uzycia: "1) przyloz cos 
o znanym wymiarze (CD, karta kredytowa, banknot) do obrazka na ekranie, 
2) klikaj +/- aż obraz na ekranie pokryje sie z Twoim przedmiotem".


> 96 pikseli na ekranie o szerokości przy gęstości pikseli 493ppi powinny
> dać kwadrat o boku 0.194 cala a nie 2/3 cala jak wyżej napisałem.
>
> Kolejny eksperyment: za pomocą JS zmierzyłem szerokość ekranu (portrait)
> i wyniosła 412px a spodziewałem się 1440px.
>
> O co chodzi????

Potknąłeś się o "pixel-ratio". Przegladarka operuje na abstrakcyjnych 
pikselach CSS-owych ("CSS pixels"). Ktos kiedys sobie policzyl, ze na 
monitorze stojacym w odpowiedniej odleglosci od uzytkownika na jednym 
calu miesci sie 96 pikseli. Taki typowy monitor o gestosci zblizonej do 
96 ppi ma pixel-ratio = 1. Urzadzenia mobilne maja ekrany o duzo 
wyzszych gestosciach i zglaszaja przegladarce wartosci pixel-ratio np. 
2, 3. Nexus 6 ma pixel-ratio = 3.5, dlatego dla przegladarki ekran 
Nexusa 6 ma wymiary 412 x 690 px - kazdy CSS piksel jest "rzutowany" na 
3,5 x 3,5 pikseli fizycznych.

W media queries ekran o duzej gestosci wykrywa sie za pomoca 
nieoficjalnej wlasnosci "device-pixel-ratio" (z prefiksami) lub 
standardowej, choc nie wszedzie wspieranej "resolution", np.

@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (   min--moz-device-pixel-ratio: 2),
only screen and (     -o-min-device-pixel-ratio: 2/1),
only screen and (        min-device-pixel-ratio: 2),
only screen and (                min-resolution: 192dpi),
only screen and (                min-resolution: 2dppx) {
   /* Retina stuff */
}
Zrodlo: https://css-tricks.com/snippets/css/retina-display-media-query/
Wsparcie: http://caniuse.com/#feat=css-media-resolution


Przy czym wykrywanie gestosci ma sens glownie przy serwowaniu grafik 
dedykowanych dla duzych gestosci, natomiast wymiarujac serwis zwykle 
wystarczy operowac w media queries na przedzialach szerokosci 
zdefiniowanych w CSS pikselach lub jednostkach relatywnych.

-- 
NotBear

W dniu 29.05.2016 o 19:57, NotBear pisze:


Hej

> O fizycznych jednostkach na ekranie lepiej zapomniec

Tak, koledzy już mi o tym powiedzieli.
Zupełnie nie rozumiem czemu wprowadzono cale do jednostek w CSS skoro 
nie ma to żadnej wartości. :(

> Potknąłeś się o "pixel-ratio". Przegladarka operuje na abstrakcyjnych
> pikselach CSS-owych ("CSS pixels"). Ktos kiedys sobie policzyl, ze na
> monitorze stojacym w odpowiedniej odleglosci od uzytkownika na jednym
> calu miesci sie 96 pikseli.

Tak na marginesie - odległość od monitora nie ma tu zastosowania. Jeśli 
96 pikseli zmierzone suwmiarką to 2.54cm, to znaczy, że wyświetlacz ma 
96dpi. Jednostki dpi są bardzo precyzyjnie określone. Nie ma tu miejsca 
na interpretacje, odległości od monitora itp.

> wystarczy operowac w media queries na przedzialach szerokosci
> zdefiniowanych w CSS pikselach lub jednostkach relatywnych.

Tak też zrobię. Pixel ratio wydaje mi się prowizorką. No ale cóż, skoro 
inaczej nie można, to nie pozostaje mi nic innego jak dostosować się. 
Dziękuję Ci za pomoc.

-- 
Pozdrawiam,
Marek

W dniu 2016-05-29 o 23:35, Marek pisze:
> Zupełnie nie rozumiem czemu wprowadzono cale do jednostek w CSS skoro
> nie ma to żadnej wartości. :(

Ma sens dla @media print


> Tak na marginesie - odległość od monitora nie ma tu zastosowania. [...]

Ma, gdyz piksel jest definiowany jako miara katowa: "The reference pixel 
is the visual angle of one pixel on a device with a pixel density of 
96dpi and a distance from the reader of an arm’s length. For a nominal 
arm’s length of 28 inches, the visual angle is therefore about 0.0213 
degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 
mm (1/96 inch)."

https://www.w3.org/TR/css3-values/#absolute-lengths

Idea jest taka, zeby uwzglednic sposob uzytkowania ekranu. Element 
dlugosci 100px wyswietlony na monitorze stojacym na biurku winien miec 
wizualnie podobna wielkosc jak np na odleglym ekranie na scianie lub 
smartfonie trzymanym blisko w reku (za to pomiar suwmiarka wykaze 
znaczna rozbieznosc :-).


> Pixel ratio wydaje mi się prowizorką.

Bo to bardziej sie przydaje tworcom przegladarek, zeby poprawnie 
zachowywaly sie na roznych gestosciach ekranow :-)

Tworcom stron glownie do optymalnego serwowania grafiki rastrowej.


-- 
NotBear

W dniu 30.05.2016 o 22:03, NotBear pisze:

> W dniu 2016-05-29 o 23:35, Marek pisze:
>> Zupełnie nie rozumiem czemu wprowadzono cale do jednostek w CSS skoro
>> nie ma to żadnej wartości. :(
>
> Ma sens dla @media print

Sprawdzałeś czy to tam działa? Być może też tam wymyślono, że cal ma 96 
px lub coś podobnie absurdalnego.

Ponadto tak czy owak nie rozumiem dlaczego dla mediów ekranowych tak 
samo to działać nie chce. DPI w obu tych przypadkach jest jednoznaczne. 
Przekombinowane to wszystko... ehhh.

Właśnie czytając to, co poniżej napisałeś doszedłem do wniosku, że też 
nie działa. Ale o tym poniżej.

> Ma, gdyz piksel jest definiowany jako miara katowa: "The reference pixel
> is the visual angle of one pixel on a device with a pixel density of
> 96dpi and a distance from the reader of an arm’s length. For a nominal
> arm’s length of 28 inches, the visual angle is therefore about 0.0213
> degrees. For reading at arm’s length, 1px thus corresponds to about 0.26
> mm (1/96 inch)."
>
> https://www.w3.org/TR/css3-values/#absolute-lengths
>
> Idea jest taka, zeby uwzglednic sposob uzytkowania ekranu. Element
> dlugosci 100px wyswietlony na monitorze stojacym na biurku winien miec
> wizualnie podobna wielkosc jak np na odleglym ekranie na scianie lub
> smartfonie trzymanym blisko w reku (za to pomiar suwmiarka wykaze
> znaczna rozbieznosc :-).

Aaahaaa... załapałem w czym rzecz! Podejściem CSS jest wizualizacja a 
nie trzymanie się jednostek fizycznych i stąd moje niezrozumienie 
jednostek fizycznych w interpretacji CSS.

Przy okazji zwróć uwagę, że w tym artykule pokazane jest jak piksel 
wyświetlacza zamieniany jest na szereg pikseli drukarki. Czyli DPI 
również jest tu syntetyczne i kompletnie niczego nie oznacza.

> Bo to bardziej sie przydaje tworcom przegladarek, zeby poprawnie
> zachowywaly sie na roznych gestosciach ekranow :-)
>
> Tworcom stron glownie do optymalnego serwowania grafiki rastrowej.

Kumam :-)

-- 
Pozdrawiam,
Marek

----- Original Message ----- 
From: "Marek" <precz@spamowi.com>
Newsgroups: pl.comp.www
Sent: Tuesday, May 31, 2016 11:07 AM
Subject: Re: Wykrywanie urządzeń w RWD. Ile cali ma cal?


>W dniu 30.05.2016 o 22:03, NotBear pisze:
>
>> W dniu 2016-05-29 o 23:35, Marek pisze:
>>> Zupełnie nie rozumiem czemu wprowadzono cale do jednostek w CSS skoro
>>> nie ma to żadnej wartości. :(
>>
>> Ma sens dla @media print
>
> Sprawdzałeś czy to tam działa? Być może też tam wymyślono, że cal ma 96 px 
> lub coś podobnie absurdalnego.


Ja na wydrukach używam jednostkę "pt"
Jest to 1/72 cala. 

W dniu 2016-05-31 o 11:07, Marek pisze:
> Sprawdzałeś czy to tam działa?

Masz mnie! :-)

Lata temu robilem CSSy do druku, ale przyznaje sie, ze nigdy nie 
sprawdzalem co do milimetra tego co wyszlo.

Sprawdzilem teraz i z trojki: Chrome, Fx, IE11 tylko ten trzeci (sic!) 
poprawnie wypuscil na drukarke element o wielkosci zadanej w calach. W 
pozostalych dochodzi do skalowania w dol.

p {
   border:1px solid black; display:block; width:2in; height:2in;
}


Po dodaniu regul jak nizej Chrome rowniez wydrukowal poprawne wymiary, 
Firefoxa nie udalo sie zmusic do lepszej wspolpracy...

@page {
   size: A4; margin: 0;
}
html, body {
   width: 210mm; height: 297mm; margin: 0; padding: 0;
}


-- 
NotBear

W dniu 02.06.2016 o 20:57, NotBear pisze:
> W dniu 2016-05-31 o 11:07, Marek pisze:
>> Sprawdzałeś czy to tam działa?
>
> Masz mnie! :-)
>

Olać to :) Należy przyjąć, że CSS (w uproszczeniu) tak ma i nie 
przejmować się tym. Tak, jak przytoczyłeś: piksele w CSS to zabawy z 
kątami patrzenia itp. Krótko mówiąc wielkości fizyczne stają się wtedy 
wielkościami uznaniowymi. Jak ja to kocham... No ale jest jak jest.

-- 
Pozdrawiam,
Marek

Dnia Sat, 28 May 2016 13:31:58 +0200, Marek napisał(a):

> Zrobiłbym tak (opisowo):
> 
> if media resolution<100dpi
> font-size: 12px
> 
> else if media resolution<200dpi
> font-size: 24px
> 
> else
> font-size: 36px

I wymyśliłeś media queries, tylko trudniejsze w obsłudze :)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 03.06.2016 o 11:27, Borys Pogoreło pisze:
>
> I wymyśliłeś media queries, tylko trudniejsze w obsłudze :)
>

Serio? Czemu tak uważasz? Zresztą nie ja to wymyśliłem lecz resolution 
jest parametrem media queries. Wydaje mi się dużo prostsze panowanie nad 
wielkością tekstu (w szczególności) gdy znamy DPI urządzenia. Operowanie 
szerokościami pikselowymi wydaje mi się abstrakcyjne bo po pierwsze sam 
zauważyłeś, że piksel w ujęciu CSS jest jednostką wyssaną z palca i 
zależy od widzimisię producenta danego urządzenia.

Po drugie - te jednostki nie mają sensu bo nie wiemy czy na ekranie o 
szerokości 1000px czcionka 12px będzie mikroskopijna, czy też wielkości 
konia bo to zależy jak duży jest piksel na danym urządzeniu. Natomiast 
przy DPI wartości są jednoznaczne.

-- 
Pozdrawiam,
Marek

Dnia Fri, 3 Jun 2016 22:30:41 +0200, Marek napisał(a):

>> I wymyśliłeś media queries, tylko trudniejsze w obsłudze :)
> 
> Serio? Czemu tak uważasz? 

Bo musiałbyś pisać reguły dla *wszystkich* elementów dla *każdej* możliwej
gęstości ekranu. Albo wszystko by się rozjeżdżało.

Tekst to dopiero początek problemów przy takim podejściu.

> Po drugie - te jednostki nie mają sensu bo nie wiemy czy na ekranie o 
> szerokości 1000px czcionka 12px będzie mikroskopijna, czy też wielkości 
> konia bo to zależy jak duży jest piksel na danym urządzeniu. Natomiast 
> przy DPI wartości są jednoznaczne.

Będzie "mała, ale jeszcze czytelna" - to najzupełniej wystarczy.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 04.06.2016 o 15:42, Borys Pogoreło pisze:


>
> Bo musiałbyś pisać reguły dla *wszystkich* elementów dla *każdej* możliwej
> gęstości ekranu. Albo wszystko by się rozjeżdżało.

No ale dokładnie to samo dzieje się definiując gradację pikselową 
przecież :-) Też definiujesz przedziały i określasz odrębny CSS dla 
nich. Jedyna różnica polega na tym, że robisz to chybił trafił w 
pikselach bo nie wiesz co oznacza np. 1000px - czy tablet, czy telefon 
czy jeszcze coś innego.

Przykład z życia wzięty: wspomniałeś o typowych 3 podziałach, cytuję:

"do 768px (telefon), do 1024px (tablet) i powyżej (desktop)"

Z ciekawości sprawdziłem to na moim telefonie (Nexus 6). Na 768 nie 
zareagował. Gdy podałem wyssane z palca 1000px - wtedy detekcja 
przeszła. Na drugim telefonie Nexusie 5x - podobnie. Na podobnych 
wymiarów wiekowym HTC Desire HD zadziałało już przy 768. Tak więc 
widzisz - podziały pikselowe ... jak to ktoś powiedział ... istnieją 
tylko teoretycznie. :-)

Przy DPI kryteria byłyby dużo bardziej jednoznaczne a ilość podziałów 
byłaby dokładnie taka sama jak przy nie jednoznacznych pikselach. Jedyna 
różnica byłaby w precyzji detekcji wyłącznie.

> Tekst to dopiero początek problemów przy takim podejściu.

Wydaje mi się, że problem byłby identyczny gdyż mówimy jedynie o 
skuteczniejszej detekcji wielkości ekranów. Jeśli zrobisz to trafniej, 
to nie rzutuje to przecież na zmianę ilości problemów. No chyba, że 
widzisz to inaczej. Chętnie poczytam :-)

> Będzie "mała, ale jeszcze czytelna" - to najzupełniej wystarczy.

To też zależy od urządzenia. Najświeższy Android pięknie skaluje teksty, 
czy też raczej sekcje stron WWW. Strony nie-RWD z dowolną czcionką są 
doskonale widoczne. Mało tego (tak na marginesie), wkurza mnie gdy 
content strony jest RWD (np. Allegro, mBank etc) bo wtedy interfejs 
staje się ortopedyczny. Wszystko duże i kwadratowe jak dla niewidomych i 
zajmujące czasem N ekranów w dół a i często jest okrojona funkcjonalność 
przy okazji. Nie ma żadnego problemu z oglądaniem zwykłych "startych" 
stron WWW. Dwukrotne kliknięcie powiększa do danej kolumny jeśli jest 
nieczytelna. Ponowne - przywraca view. Wszystko łatwe, intuicyjne i 
przyjemne. Jednakże ten podział na tablety i inne jest znakiem czasów i 
trzeba się dostosować... ehhh

-- 
Pozdrawiam,
Marek

Dnia Sat, 4 Jun 2016 18:20:09 +0200, Marek napisał(a):

>> Bo musiałbyś pisać reguły dla *wszystkich* elementów dla *każdej* możliwej
>> gęstości ekranu. Albo wszystko by się rozjeżdżało.
> 
> No ale dokładnie to samo dzieje się definiując gradację pikselową 
> przecież :-) Też definiujesz przedziały i określasz odrębny CSS dla 
> nich. 

Nie, definiujesz element raz, a później ew. wyjątki. Przy kombinacjach z
DPI musiałbyś pisać wprost reguły dla każdego możliwego ekranu i jeszcze
przewidzieć w przód dalsze zwiększanie gęstości. 

> Z ciekawości sprawdziłem to na moim telefonie (Nexus 6). Na 768 nie 
> zareagował. Gdy podałem wyssane z palca 1000px - wtedy detekcja 
> przeszła. 

A to dziwne, bo podobno ma 412px w poziomie.

> Na drugim telefonie Nexusie 5x - podobnie. Na podobnych 
> wymiarów wiekowym HTC Desire HD zadziałało już przy 768. Tak więc 
> widzisz - podziały pikselowe ... jak to ktoś powiedział ... istnieją 
> tylko teoretycznie. :-)

Oczywiście, ale to najlepsze co mamy. Taki sam problem jest z wykryciem,
czy użytkownik korzysta z dotyku czy z myszy (a może z obu?).

> Przy DPI kryteria byłyby dużo bardziej jednoznaczne a ilość podziałów 
> byłaby dokładnie taka sama jak przy nie jednoznacznych pikselach. Jedyna 
> różnica byłaby w precyzji detekcji wyłącznie.

A jak byś rozwiązał kwestię dostosowania interfejsu do sposobu korzystania
z urządzenia? Wysokie dpi równie dobrze może oznaczać ekran typu Retina w
17-calowej makówce.

> To też zależy od urządzenia. Najświeższy Android pięknie skaluje teksty, 
> czy też raczej sekcje stron WWW. Strony nie-RWD z dowolną czcionką są 
> doskonale widoczne. Mało tego (tak na marginesie), wkurza mnie gdy 
> content strony jest RWD (np. Allegro, mBank etc) bo wtedy interfejs 
> staje się ortopedyczny. Wszystko duże i kwadratowe jak dla niewidomych i 
> zajmujące czasem N ekranów w dół a i często jest okrojona funkcjonalność 
> przy okazji. Nie ma żadnego problemu z oglądaniem zwykłych "startych" 
> stron WWW. Dwukrotne kliknięcie powiększa do danej kolumny jeśli jest 
> nieczytelna. Ponowne - przywraca view. Wszystko łatwe, intuicyjne i 
> przyjemne. 

Chyba mamy inną definicję "łatwego" i "intuicyjnego", jeśli trzeba
powiększać fragmenty, by korzystać ze strony. Z dobrze zrobionej [1]
"ortopedycznej" strony korzysta się bez problemów.

[1] Okrojona funkcjonalność to nie jest dobrze zrobiona strona (choć i od
tego są wyjątki)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 04.06.2016 o 22:31, Borys Pogoreło pisze:

 >> No ale dokładnie to samo dzieje się definiując gradację pikselową
 >> przecież :-) Też definiujesz przedziały i określasz odrębny CSS dla
 >> nich.
 >
 > Nie, definiujesz element raz, a później ew. wyjątki. Przy kombinacjach z
 > DPI musiałbyś pisać wprost reguły dla każdego możliwego ekranu i jeszcze
 > przewidzieć w przód dalsze zwiększanie gęstości.

Szczerze mówiąc nie łapię nadal dlaczego tak uważasz. Załóżmy 
hipotetycznie, że 768 px odpowiada 200 dpi. Jeśli określisz zmianę CSS 
przy 768 px lub przy 200 dpi skutek będzie identyczny przecież.

 >> Z ciekawości sprawdziłem to na moim telefonie (Nexus 6). Na 768 nie
 >> zareagował. Gdy podałem wyssane z palca 1000px - wtedy detekcja
 >> przeszła.
 >
 > A to dziwne, bo podobno ma 412px w poziomie.

Tak, właśnie to sam wcześniej sprawdziłem. JavaScripr zwraca mi 
szerokość ekranu (w trybie portrait) jako właśnie 412px a media 
min/max-width ma się nijak do tego. Stąd m.in. moje dywagacje.

 >> Na drugim telefonie Nexusie 5x - podobnie. Na podobnych
 >> wymiarów wiekowym HTC Desire HD zadziałało już przy 768. Tak więc
 >> widzisz - podziały pikselowe ... jak to ktoś powiedział ... istnieją
 >> tylko teoretycznie. :-)
 >
 > Oczywiście, ale to najlepsze co mamy. Taki sam problem jest z wykryciem,
 > czy użytkownik korzysta z dotyku czy z myszy (a może z obu?).

Zgodzę się z Tobą, że musimy pracować na tym co mamy. Ale rozważając już 
czysto akademicko zupełnie nie rozumiem tego zamieszania. DPI jest 
jednoznaczne a piksele CSS są z dupy wzięte (powołując się na w/w 
przykład). Nie sprawdza się tu w ogóle zasada CSS, że piksele są 
pikselami kątowymi. Bez żadnego kombinowania dpi byłoby jednoznaczne. 
Więcej o moich przemyśleniach poniżej, gdzie przedstawiam własną wizję :-)

 >> Przy DPI kryteria byłyby dużo bardziej jednoznaczne a ilość podziałów
 >> byłaby dokładnie taka sama jak przy nie jednoznacznych pikselach. Jedyna
 >> różnica byłaby w precyzji detekcji wyłącznie.
 >
 > A jak byś rozwiązał kwestię dostosowania interfejsu do sposobu 
korzystania
 > z urządzenia? Wysokie dpi równie dobrze może oznaczać ekran typu Retina w
 > 17-calowej makówce.

Tak, zastanawiałem się nad tym. W końcu N dpi na billboardzie 
elektronicznym (który swoją drogą ma być zakazany przy ulicach - nie 
wiem czy słyszałeś o tym) powinno uwzględniać odległość oglądania. 
Dlatego wprowadziłbym fizyczne i wizualne DPI. Fizyczne, to jednostka 
nie wymagająca komentarza. Wizualne - to DPI po uwzględnieniu pixel 
ratio zależne od założonej odległości oglądania i rozdzielczości i 
wielkości ekranu. W zależności od tego jaka intencję ma autor treści 
strony WWW, takie przełączniki CSS uwzględnia. Jeśli zależy mu aby cal 
wynosił 2.54cm na ekranie, to stosuje fizyczne DPI. Jeśli zwisa mu to i 
np. obrazowo chce przedstawić kwadrat o boku 1 cala tak aby z odległości 
"ulicznej" ktoś zobaczył tą figurę w sensie zobrazowania a nie używania 
jako jednostki miary - wybiera DPI relatywne dla urządzenia (wizualne) 
jako przełącznik CSS. Wydaje mi się to najbardziej banalnym podejściem, 
bez kombinowania co autor przeglądarki WWW (i to dla danego urządzenia) 
miał na myśli.

 > Chyba mamy inną definicję "łatwego" i "intuicyjnego", jeśli trzeba
 > powiększać fragmenty, by korzystać ze strony. Z dobrze zrobionej [1]
 > "ortopedycznej" strony korzysta się bez problemów.

Tak, to prawda. Intuicyjność zależna jest od użytkownika i może 
wywoływać skrajnie różne odczucia. No ale tu ciężko o kompromis. Ja 
trafiając na jakąś stronę WWW, która ma przycisk "przełącz do wersji 
klasycznej", natychmiast go używam. Dużo lepiej czyta mi się zawartość 
widząc całość powiększając i wycofując się z powiększenia szybkim gestem 
z fragmentu strony niż przewijając w nieskończoność w dół ortopedyczną 
stronę, nie wiedząc co mnie spotka po kolejnym przewinięciu. 
Podświadomie oczekuję uporządkowanego przekazu zamiast stochastycznego. 
Wspomniałem o tym jedynie w ramach ciekawostki, bo raczej tu niczego 
konstruktywnego nie )

-- 
Pozdrawiam,
Marek

Dnia Sun, 5 Jun 2016 23:39:06 +0200, Marek napisał(a):

>  > Nie, definiujesz element raz, a później ew. wyjątki. Przy kombinacjach z
>  > DPI musiałbyś pisać wprost reguły dla każdego możliwego ekranu i jeszcze
>  > przewidzieć w przód dalsze zwiększanie gęstości.
> 
> Szczerze mówiąc nie łapię nadal dlaczego tak uważasz. Załóżmy 
> hipotetycznie, że 768 px odpowiada 200 dpi. Jeśli określisz zmianę CSS 
> przy 768 px lub przy 200 dpi skutek będzie identyczny przecież.

Pewnego dnia przyjdą ekrany 400dpi i nagle strona będzie dwa razy za mała.
Będziesz za każdym razem poprawiać CSS-y? O piksele "logiczne" martwi się
producent telefonu lub przeglądarki.

>  > A to dziwne, bo podobno ma 412px w poziomie.
> 
> Tak, właśnie to sam wcześniej sprawdziłem. JavaScripr zwraca mi 
> szerokość ekranu (w trybie portrait) jako właśnie 412px a media 
> min/max-width ma się nijak do tego. Stąd m.in. moje dywagacje.

Na to pewnie jest proste wytłumaczenie o nazwie "Android" ;)

(nie pierwszy i nie ostatni problem)

> Zgodzę się z Tobą, że musimy pracować na tym co mamy. Ale rozważając już 
> czysto akademicko zupełnie nie rozumiem tego zamieszania. DPI jest 
> jednoznaczne a piksele CSS są z dupy wzięte (powołując się na w/w 
> przykład). Nie sprawdza się tu w ogóle zasada CSS, że piksele są 
> pikselami kątowymi. 

Nie będą co do ułamka sekundy kątowej, ale widać w miarę wyraźnie stosunek
rozdzielczości "logicznej" do wielkości ekranu (+/- wyjątki jakichś
kreatywnych producentów).

> Tak, zastanawiałem się nad tym. W końcu N dpi na billboardzie 
> elektronicznym (który swoją drogą ma być zakazany przy ulicach - nie 
> wiem czy słyszałeś o tym) 

I bardzo dobrze, nienawidzę ich. Jedziesz sobie w nocy, a tu nagle
dostajesz lampą po oczach.

> Dlatego wprowadziłbym fizyczne i wizualne DPI. 

Widzę, że Firefox ma coś takiego jak "mozmm", które miało być "fizycznym
milimetrem" o którym piszesz, ale jak widać nie ma na to zapotrzebowania i
temat jest śladowo opisany.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 07.06.2016 o 22:11, Borys Pogoreło pisze:

> Pewnego dnia przyjdą ekrany 400dpi i nagle strona będzie dwa razy za mała.

No ale dokładnie ten sam problem istnieje przy definiowaniu pikselowych 
podziałów. Na monitorach 4k będziesz miał 2048px, 4096px itd. Wszystko 
zależy od tego co przeglądarka zaanonsuje. Czytaj poniżej.

> Będziesz za każdym razem poprawiać CSS-y? O piksele "logiczne" martwi się
> producent telefonu lub przeglądarki.

Właśnie... a jak odkryłem, u mnie anonsuje brednie i jest czym się 
martwić na Nexusie 6. I znów czytaj dalej zanim skomentujesz :-)

>>  > A to dziwne, bo podobno ma 412px w poziomie.
>>
>> Tak, właśnie to sam wcześniej sprawdziłem. JavaScripr zwraca mi
>> szerokość ekranu (w trybie portrait) jako właśnie 412px a media
>> min/max-width ma się nijak do tego. Stąd m.in. moje dywagacje.
>
> Na to pewnie jest proste wytłumaczenie o nazwie "Android" ;)

No więc właśnie. Takich wytłumaczeń pewnie znajdzie się od zarypania. I 
co wtedy? To są przecież realne sytuacje. Będziesz generował oddzielne 
CSSy dla każdego "wytłumaczenia"? Dlatego optuję za DPI bo to jest 
jednoznaczne. Jeśli np. skończyłem z CSS dla 200 dpi a powstanie 400dpi 
to wielka krzywda się nie stanie bo telefon (Android) zręcznie skalować 
potrafi. Ewentualnie zyskam nowe zlecenie na dodanie kolejnego CSS. :-)

Tu miejsce na Twój komentarz :-D

> Nie będą co do ułamka sekundy kątowej, ale widać w miarę wyraźnie stosunek
> rozdzielczości "logicznej" do wielkości ekranu (+/- wyjątki jakichś
> kreatywnych producentów).

Powtórzę swoje uparcie :-D Na Nexusie 6 mogę zignorować wersje RWD i 
zawsze wygląda strona dobrze i czytelnie. Dlatego miotam się pomiedzy 
stosowaniem RWD, które zależne jest od tego co w dłoni trzymam i wybór 
CSS dla danego urządzenia jest taki jak producent telefonu sobie 
wymyślił (czyli przypadkowy).

>> Tak, zastanawiałem się nad tym. W końcu N dpi na billboardzie
>> elektronicznym (który swoją drogą ma być zakazany przy ulicach - nie
>> wiem czy słyszałeś o tym)
>
> I bardzo dobrze, nienawidzę ich. Jedziesz sobie w nocy, a tu nagle
> dostajesz lampą po oczach.

Witaj w klubie :-) Zapewne w końcu ktoś nie uległ "lobby" wreszcie.

> Widzę, że Firefox ma coś takiego jak "mozmm", które miało być "fizycznym
> milimetrem" o którym piszesz, ale jak widać nie ma na to zapotrzebowania i
> temat jest śladowo opisany.

W zasadzie nie chodzi o mm tylko o DPI. Mając mm byłoby trzeba sztuczki 
w JS wymyślać aby przeliczyć to na DPI. Jednakże nie trzeba kombinować 
lecz wykorzystać to co już istnieje:

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#resolution

A nie działa ogólnie rzecz ujmując...


-- 
Pozdrawiam,
Marek

Dnia Tue, 7 Jun 2016 22:38:35 +0200, Marek napisał(a):

>> Pewnego dnia przyjdą ekrany 400dpi i nagle strona będzie dwa razy za mała.
> 
> No ale dokładnie ten sam problem istnieje przy definiowaniu pikselowych 
> podziałów. Na monitorach 4k będziesz miał 2048px, 4096px itd. Wszystko 
> zależy od tego co przeglądarka zaanonsuje. Czytaj poniżej.

Szerokość strony ma pewne granice rozsądku, nie ma sensu robić szerszej
treści, niż 1200-1400px, bo nikt tego nie obejmie wzrokiem.

DPI ma granicę jedynie w kreatywności producentów w gonitwie na cyferki.

> Właśnie... a jak odkryłem, u mnie anonsuje brednie i jest czym się 
> No więc właśnie. Takich wytłumaczeń pewnie znajdzie się od zarypania. I 
> co wtedy? To są przecież realne sytuacje. Będziesz generował oddzielne 
> CSSy dla każdego "wytłumaczenia"? 

Nie, media queries są wystarczająco skuteczne, by objąć większość urządzeń.
Jeśli producent Nexusa ma jakieś swoje pomysły, to trudno.

Nawiasem mówiąc nie wierzę, że tak znana marka ma tak podstawowy problem.
Jaki napis tu widzisz na tym telefonie:
http://foundation.zurb.com/sites/docs/interchange.html ?

> Dlatego optuję za DPI bo to jest 
> jednoznaczne. Jeśli np. skończyłem z CSS dla 200 dpi a powstanie 400dpi 
> to wielka krzywda się nie stanie bo telefon (Android) zręcznie skalować 
> potrafi. Ewentualnie zyskam nowe zlecenie na dodanie kolejnego CSS. :-)

Uhm. I będziesz poprawiać wszystkie strony, które zrobiłeś do tej pory, z
tego część charytatywnie?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Użytkownik "Borys Pogoreło" <borys@pl.edu.leszno> napisał w wiadomości 
news:lf95o0drqcoo.1rn58essa89ei.dlg@40tude.net...
> Dnia Sun, 5 Jun 2016 23:39:06 +0200, Marek napisał(a):
>

> Pewnego dnia przyjdą ekrany 400dpi i nagle [...]

:)
One juz dawno przyszły.
I poszły jeszcze dalej. 

Dnia Thu, 9 Jun 2016 13:10:44 +0200, tomek napisał(a):

>> Pewnego dnia przyjdą ekrany 400dpi i nagle [...]
> 
> :)
> One juz dawno przyszły.
> I poszły jeszcze dalej.

No to 600 ;) Wierzę, że marketoidy dadzą radę i więcej.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 08.06.2016 o 20:50, Borys Pogoreło pisze:

>> No ale dokładnie ten sam problem istnieje przy definiowaniu pikselowych
>> podziałów. Na monitorach 4k będziesz miał 2048px, 4096px itd. Wszystko
>> zależy od tego co przeglądarka zaanonsuje. Czytaj poniżej.
>
> Szerokość strony ma pewne granice rozsądku, nie ma sensu robić szerszej
> treści, niż 1200-1400px, bo nikt tego nie obejmie wzrokiem.

Niezupełnie. Na monitorze 4k szerokość strony 1200px wygląda jak znaczek 
pocztowy :-) M.in. z tego powodu DPI są istotne.

> DPI ma granicę jedynie w kreatywności producentów w gonitwie na cyferki.

Owszem, masz rację ale nie unikniesz partycypacji w tej gonitwie jako 
webmaster.

> Nie, media queries są wystarczająco skuteczne, by objąć większość urządzeń.
> Jeśli producent Nexusa ma jakieś swoje pomysły, to trudno.

No coś Ty. Np. monitor Samsung UHD 28" 4K LU28E590DS ma rozdzielczość 
3840x2160. Kosztuje ok 1900zł więc sprzęt taki zaraz zawita pod 
strzechy. A takich monitorów jest już od groma na rynku.

> Nawiasem mówiąc nie wierzę, że tak znana marka ma tak podstawowy problem.
> Jaki napis tu widzisz na tym telefonie:
> http://foundation.zurb.com/sites/docs/interchange.html ?

Tak to widzę:

https://drive.google.com/file/d/0B5EZBCDOXXP7MUFZeXBwejhzbHM/view?usp=sharing

Górny tekst ogromny, a dolny trochę jak dla niedowidzących :-) A czemu 
pytasz?


>> Dlatego optuję za DPI bo to jest
>> jednoznaczne. Jeśli np. skończyłem z CSS dla 200 dpi a powstanie 400dpi
>> to wielka krzywda się nie stanie bo telefon (Android) zręcznie skalować
>> potrafi. Ewentualnie zyskam nowe zlecenie na dodanie kolejnego CSS. :-)
>
> Uhm. I będziesz poprawiać wszystkie strony, które zrobiłeś do tej pory, z
> tego część charytatywnie?

Nigdy! Za kasę! :-D Tak samo nie poprawiam za darmo stron jakie we 
Flashu robiłem ileś lat temu. Rozwój technologii jest jaki jest, nie da 
się przewidywać na X lat do przodu no i klient musi się z tym liczyć.


-- 
Pozdrawiam,
Marek