ugrás a tartalomhoz

Media query-k

Dinnye · 2018. Okt. 26. (P), 13.40
Sziasztok!

(Nem vagyok webprogramozó, "tudásom" 100%-a Google és fórumok, szóval kélek legyetek velem elnézőek! köszi!)

Egy responsive weboldalt szeretnék készíteni. Elég sokat olvasgattam, hogy a media query-kel mik az optimális / legelterjedtebb töréspontok, de ezer-féle elképzelést találtam, így kissé elbizonytalanodtam.

Én erre gondoltam: @media only screen and (max-width: 1024px, 768px, 480px), 300px alá pedig ne menjen.

Ultra kicsi felbontású kütyükre nem optimalizálnék, mint pl.: okosórák meg a szomszéd mikrosütője, a "klasszikus" eszközökön legyen használható (számítógép / laptop / tablet / okosteló). Az oldal tartalma alapján ennek van értelme.

Ti milyen töréspontokat javasoltok?
Illetve érdemes-e beállítani minimális / maximális szélességet és ha igen, mekkorát?
‹ Slider oldalbetöltés Event table / queue / loop és a többiek ›
 ■
1

Nincs fix méret

Endyl · 2018. Okt. 26. (P), 17.23
Annyi féle eszköz van, hogy nem fogsz általánosan használható fix számokat találni.

Elkezded készíteni az oldaladat responsive design viewban a legkisebb méretben, amit támogatni akarsz. Ha van egy jól működő felállásod, akkor elkezded növelni a képernyő méretét, amíg élvezhetetlenné nem válik. Itt létrehozol egy min-width-es media queryt és abban helyrepofozod a megjelenést. Amikor okés, utána ismétled az előzőeket.

Szóval ne eszközökhöz igazítsd a media queryket, hanem a tartalomhoz.
2

Hát nem tudom, hogy van e

inf · 2018. Okt. 27. (Szo), 07.02
Hát nem tudom, hogy van e értelme felbontás alapján belőni bármit. Mondjuk nem értek a sitebuildhez, meg a responsive designhoz, de nekem nem logikus ez az egész. Pl van egy fullhd monitorod, ami 27"-os, meg van egy mobilod, ami wqhd (2560x1440), és 6"-os link, mert Steve Jobs óta a retina screen a divat. Mindkettőre kitolja az asztali nézetet, esetleg ha fullhd-nál nagyobb felbontásra van még valami extra nézet, akkor az menni fog a mobilra is, és gyakorlatilag használhatatlan lesz az oldal mobilon, mert nem látod a betűket, annyira aprók. Vagy a kijelző fizikai méretét kellene nézni, és esetleg amellé a PPI-t, hogy mehet e rá apró betűs szöveg, vagy kell külön mobil oldal, ami választható. Esetleg erre van valami megoldás, ami felett átsiklottam?

szerk:
Ja, ahogy nézem félreérthettem valamit. A responsive design-nál nem a felbontáshoz igazítják a tartalmat, hanem hagyják, hogy kitöltse a képernyőt, ha engedi a felbontás, gondolom ilyen display: inline vagy inline-block megoldásokkal. Aztán gondolom azért kell ez min/max-width neki, hogy le legyen korlátozva, hogy mennyire szűkülhet össze vagy szélesedhet ki, anélkül, hogy használhatatlanná válna.
3

Ha problémát okoz a "retina"

Endyl · 2018. Okt. 27. (Szo), 12.50
Ha problémát okoz a "retina" display, akkor arra is van media query.

Szerintem az a szerencsés, ha a media és supports queryk nélküli css-sel mindenhol ha nem is élvezetesen, de használhatóan jelenik meg az oldal (voltaképpen ezt látják a legbutább és legrégibb böngészők). Utána a jobb képességű böngészők/készülékek extráihoz (media/supports query támogatás, szélesebb képernyő, nagyobb pixelsűrűség, stb) könnyebb hozzáigazítani az egyszerűbb megjelenést, mint a csilli-villi, fullhd kinézetet beleerőszakolni, lebutítani egy kevésbé alkalmas kliens számára.
5

Eszerint próbálom én is

Dinnye · 2018. Okt. 27. (Szo), 17.12
Eszerint próbálom én is kialakítani úgy, hogy a magas felbontású és az alacsony felbontású design között a lehető legkevesebb legyen az eltérés, és lentről felfelé optimalizálni, nem pedig fordítva. Sajnos ez valamennyire a kinézet rovására megy, de kevesebb tesztelés kell hozzá. Később aztán még lehet szépítgetni itt-ott.

Ami számottevőbb változás pl.: a 640 pixeles nézet meg a full hd között, hogy a bal oldali sidebar eltűnik, és egy hamburger menüs megoldás váltja fel, a nagy csili-vili fejléc pedig egy lényegesen kisebb csíkká szűkül össze, amiben csak az oldal címe van, képek nélkül. Az oldal háttere eltűnik és a tartalom kitölti 100%-osan a képernyőt. Bízom benne, hogy ennyi elég a mobilokhoz, bár lehet ezt már 1000px alatt érdemes lenne meglépni...

A méretek közti különbséget úgy tesztelgetem, hogy a böngésző méretét állítgatom, de akkor ha jól értem, ez így nagyjából elég is hozzá.
7

Ja, itt is azt mondják, hogy

inf · 2018. Okt. 28. (V), 17.21
Ja, itt is azt mondják, hogy inkább az egyszerűbb mobil nézet felől érdemes elindulni az asztali nézet felé, mint fordítva: link
4

Én is ettől féltem. A mostani

Dinnye · 2018. Okt. 27. (Szo), 16.32
Én is ettől féltem. A mostani mobilokon már olyan felbontások vannak, mint 1 rendes monitoron, de fizikailag a kijelző méret ennek a töredéke és attól tartottam, hogy emiatt telefonon olvashatatlanul pici lesz minden.
6

Lentről fel :)

Pepita · 2018. Okt. 28. (V), 15.14
Elkezded készíteni az oldaladat responsive design viewban a legkisebb méretben

Szóval ne eszközökhöz igazítsd a media queryket, hanem a tartalomhoz.

Mindkettővel teljesen egyetértek, annyit tennék hozzá, hogy még mindig van létjogosultsága szerintem a részben eltérő tartalomnak mobil eszközökön.
Ebből a legegyszerűbb példa a hamburgermenü, még ha html-ben azonos is az asztalival, akkor se töltessem le a mobillal az asztali css-ét, netán js-t, és pláne ne js-ből matekoljam össze a jóval gyengébb hardware-rel rendelkező kliensen.
Az oldal tartalmától / témájától függően lehet sok olyan (kiegészítő) tartalmi rész, amit mobilon nem (mind) akarunk megjeleníteni.
Ez azonban lényegesen több fejlesztői munkát igényel (több template, választhatóság, stb), mint pusztán media query-t használni, viszont teljes mértékben ki is tudja azt váltani, és átlag negyedannyi css-t (.., képet, egyebet) kell lerángatnia mobilnetről a látogatónak. (Senki ne mondja, hogy a mai mobilnet már eléggé űberfrankó; egyrészt adatforgalom után fizetsz, másrészt naponta tapasztalom, hogy Pest 25 km-es körzetében is komoly ingadozások vannak nem csak sebességben, hanem egyáltalán elérhetőségben is.)
8

Ne is mondd, most mesélte

inf · 2018. Okt. 28. (V), 17.26
Ne is mondd, most mesélte ismerősöm, hogy felment a repülőre, aztán automatikusan rácsatlakozott az ottani műholdas wifire a mobilja, és kiszámláztak neki valami 15GB adatforgalmat 4500Ft/GB áron. Gondolom auto update lerántott pár frissítést, de akkor is elég fura, hogy ekkora forgalmat generált, meg hogy nem volt alapból jelszó egy fizetős wifin, hogy elkerüljék az ilyesmit. A másik, hogy a szolgáltatónál volt egy 50 euros limit beállítva, de simán hagyták, hogy túlhasználja. Ki van ez találva... Erősen agyalok, hogy a következő mobilom még kevesebbet tudjon, mint a mostani, nem kell nekem ez a 4g, meg műholdas telo meg Isten tudja még milyen hülyeségeket találtak ki.
11

(Off) Én nem fizetném ki...

Pepita · 2018. Okt. 29. (H), 09.33
Nincs rajta jelszó
Már elnézést, de lehetek én tök hülye is hozzá, és azt se tudom, hogy hova - mire - miért csatlakozik a telóm. Ha van netem, használom, ha nincs, megvárom, míg lesz.
Ha ennyit értek hozzá, akkor nincs az a szolgáltatás, amiért fizetnék, ha nem szándékosan használom.
Azt oldja meg a (wifi)szolgáltató, hogy csak akkor tudjam használni, ha fizetek érte.
A mobil szolgáltató limit nem vonatkozik (nem is vonatkozhat) wifi szolgáltatásra. Azt a forgalmat nem tudja mérni a mobilszolgáltató, max a teló tud mondjuk API-n beküldeni neki adatot, de az meg hackelhető. A repülős wifi másik szolgáltatás és szolgáltató szerintem.
12

Azt mondja, hogy azt is

inf · 2018. Okt. 29. (H), 14.28
Azt mondja, hogy azt is tudják mérni realtime, nem csak úgy továbbszámlázták. Bár én kétlem, lehet, hogy csak SMS-t küldtek, hogy biztosan akarja e használni. Lényeg a lényeg, ő ezt így nem engedélyezte, nem is kérdezték meg, de simán kiszámláztak 60k-t. Meg se nézte a mobilját, amíg hazaért az USA-ból a repülőúton... Full laikus a témában amúgy, jól beszopatták.
13

ki mit szolgáltat?

Pepita · 2018. Okt. 30. (K), 10.00
Lehet már én keverem össze a dolgokat, de még mindig nem értem, hogy egy wifin bármilyen netet szolgáltató cég hogyan tudja ennek az árát az ő hozzájárulása nélkül hozzácsapni a mobilszolgáltatója számlájához.
Valahol valamilyen formában ehhez neki kattintani kellett. Enélkül a mobilszolgáltatója se fogadhatja be a számlázási kérést.
Az olyan lenne, mintha te elmész egy tárgyalásra, megkínálnak ásványvízzel, majd a tárgyalás után nem engednek ki, amíg le nem perkálsz x lóvét érte...
A wifin bonyolított forgalmat is lehet mérni, de azt a wifit üzemeltető tudja, és jelen esetben úgy tűnik, ez külön cég. Tehát ő mondjuk a magyar A szolgáltató előfizetője, és a repülőn a (mondjuk) amerikai B szolgáltató adott neki wifin internetet.
B tudja, hogy mennyi adatforgalma volt, és ezért kér x pénzt. Ahhoz kell a user hozzájárulása, hogy ezt a pénzt B A-n keresztül, a mobilszámlához csapva kapja meg.
Ha nem ez történt, és mindenfajta hozzájárulás nélkül próbálja meg A beszedni a B-nek járó díjat, akkor -> fogyasztóvédelem. Mondjuk nem tudom, hogy mennyire aktívak manapság...
14

Nekem is ez volt a logikám,

inf · 2018. Okt. 30. (K), 15.35
Nekem is ez volt a logikám, de azt mondja, hogy elő se szedte a mobilját az egész repülőút alatt. És otthon látott valami sms-t a témában, ami azt írta, hogy fizetős hálózaton van, vagy valami ilyesmi. Ennél konkrétabbat nem tudok. Mindenesetre elég fura, hogy ez így mehet. Megérne egy pert...
9

Ez biztos így van, viszont

Dinnye · 2018. Okt. 28. (V), 22.29
Ez biztos így van, viszont azért nem akarok eltérő tartalmat az egyes eszközök között, mert az én esetemben felesleges. Ha a képgalériát nem számolom, az egész weboldal belefér majd néhány megába. Egy alapszintű hírfal dátumokkal, havi 1-2 cikkel, a többi menüpont főként szövegből, kevés képből, táblázatokból meg pár letölthető pdf doksiból áll és ennyi. Nincs sok megjelenítendő tartalom, így szerintem nagy adatforgalmat se fog generálni. JS is csak a képgalériához kell, amúgy minden máshoz html-t meg css-t használok egy nagyon minimális php-val.
10

Nem kötelező :)

Pepita · 2018. Okt. 29. (H), 09.26
Mint írtam is, téma és tartalomfüggő, nem feltétlen kell az ágyúval lőni a verébre.. :)

Ha a képgalériát nem számolom ...
Azért csak számold, és azt is, hogy mobilon is szeretünk képeket nézegetni.

... az egész weboldal belefér majd néhány megába
Kliens szempontjából nem a weboldal tárhelyigénye számít, hanem egy - egy oldal mérete és a teljes megjelenítéséhez szükséges http requestek száma. Utóbbi a sebesség miatt fontos, előbbi az adatforgalom (és persze azon keresztül sebesség is) miatt.

Azt gondolom, hogy egy landing page akkor jó (mobilon), ha belefér 300 kbyte-ba (cache nélkül) és 20 request-be tokkal vonóval. Akkor "nagyon gatya-lassú" neten is villámgyors lesz.

De eddigi elmondásod alapján ezen a projekten nem nagyon lesz ilyen gond. :)
15

OFF

Dinnye · 2018. Nov. 7. (Sze), 11.35
Bár nem teljesen a témához tartozik, de lenne még egy rövid kérdésem, ami miatt már nem nyitnék új topicot, szóval ez kicsit off téma.

Van egy fájlom, ami php include-dal tölt be adatokat egy másik php fájlból. A betöltött fájl tartalmaz egy lenyíló divet, és ebbe szintén include-dal tölt be pár soros szövegeket egy 3. (txt) fájlból.
Tehát az include-on belül van egy újabb include.
Ezt azért találtam ki, hogy a szerkesztést egyszerűsítse, mert így csak a txt-t kell átirkálni.

Ezt a megoldást teszteltem, és látszólag működik is, csak az lenne a kérdésem, hogy egy ilyen kódsor "legit-e"? Tehát csak azért működik, mert a böngészők rugalmasabbak, vagy ez így rendben van?
Szabad-e ilyen kódsorokat egymásba építeni akár több szint mélységig?
16

A bőngésző nem látja a PHP

inf · 2018. Nov. 7. (Sze), 12.04
A bőngésző nem látja a PHP include-ot. Egyébként szabad ilyet az újrahasznosítás jegyében, vagy hogy átláthatóbb legyen a kód. Sokan sablon rendszert használnak PHP helyett ilyen célra, de az nem fog menni spagetti kóddal... Érdemes belekóstolni, mert onnantól indul, hogy elkülöníted a megjelenítést, és tetszés szerint cserélheted, aztán később az adatbázis kéréseket ha kiszervezed külön osztályokba külön interface-ek mögé, akkor meg az adatbázist tudod kicserélni másikra. Utána meg jön a DDD meghasonlók, hogy hogyan is kell ezt profi módon csinálni.
17

+1

Pepita · 2018. Nov. 7. (Sze), 12.43
Ezt nagyon jól írtad, különösen tetszik az "Érdemes belekóstolni". :)

Annyit tennék hozzá, hogy a PHP include csak egy nyelvi elem, aminek egyetlen célja, hogy segítse a fájlszintű kódszervezést, csakis annyi a szerepe, hogy - ha jól használják - ne kelljen ugyanazt többször leírni (kód-duplikáció), illetve aminek több helyen egyformának kell lennie, az egyforma is lehessen.
18

:)

Dinnye · 2018. Nov. 7. (Sze), 14.16
A külső include-nak pont ez a célja, hogy ugyanazt a felületet ne kelljen mindenhol újraírni, a belső meg szöveggel tölti fel txt-ből.
Egyszerű, mint a faék, de sokat könnyít majd.

Azon a szinten még nem tartok, hogy a fent említett dolgokba belekóstoljak. Talán majd egyszer. :)

Köszönöm szépen mindenki segítségét! :)
19

Ja ezt az egyik futós

inf · 2018. Nov. 7. (Sze), 20.46
Ja ezt az egyik futós topicból vettem át. Ott elmorzsolják a kilométereket, meg belekóstolnak a 3 perc/km tempóba, meg megrogynak, mint a rohadt nád. Egy határon túli (zentai) magyar szavajárása ez, de úgy látszik, már az enyém is. :-)
20

futós offtopic :)

mind1 valami név · 2018. Nov. 13. (K), 11.53
Minap nézegettem, hogy a maratoni távot egyesek két óra körüli idővel futják. Basszus, én bringán is örülök, ha a 15km/h átlag megvan ekkora távon. :D
21

Hát ahhoz nagyon sokat kell

inf · 2018. Nov. 13. (K), 20.14
Hát ahhoz nagyon sokat kell edzeni, meg már talán genetika is kell hozzá. Ismerős futja 2:30 körül, de már az is országos dobogó szint.
22

Na jó, de érted: bringával

mind1 valami név · 2018. Nov. 13. (K), 20.19
Na jó, de érted: bringával nem tudnám lehagyni :D
23

Én simán lehagynám bringával,

inf · 2018. Nov. 13. (K), 20.59
Én simán lehagynám bringával, 15kph nem annyira nagy szám. :-) Futásnál 12kph feletti átlag tempó már biztosan nem menne maratonnál, inkább olyan 10-11kph, ami reális lenne most, de futásnál perc/km-ben mérik, mert ott nagyon nem mindegy, hogy 6:00 (10kph) vagy 5:00 (12kph). A nagyon profik olyan 3:00-s tempót tolnak maratonon, nekem az talán párszáz méteren menne. Nem véletlen ők a profik, akik ebből élnek, én meg az amatőr. :)
24

Neked lehet, nekem sajnos az.

mind1 valami név · 2018. Nov. 13. (K), 21.07
Neked lehet, nekem sajnos az. Sík terepen, jó úton, ha megerőltetem magam, akkor tudok max. 35-36km/h-t, ha nagyon erőlködök, akkor akár 40-et is. De ez úgy 1-2km-en át, aztán lehet kapkodni levegő után. És így már szépen lemegy az átlag. Futni én max. 10-20 métert tudok, utána vagy a levegő fogy el vagy a derekam adja be a kulcsot. :D
25

Maxon senki nem tud hosszú

inf · 2018. Nov. 15. (Cs), 18.22
Maxon senki sem tud hosszú távú erőkifejtést csinálni. Meg kéne találni, hogy hol van az anaerob küszöb nálad, aztán az alatt kicsivel már menni fog hosszú távon is. Ha van pulzusmérős, GPS-es kütyüd, és sík tereped, akkor elég egyszerű megmondani. Elindulsz néhány percenként növelve a tempót (vagy a pulzust) adott mennyiséggel, aztán csinálsz egy sebesség - pulzus grafikont. Ahol megugrik a pulzus azonos sebesség növekedésre (vagy letörik a sebesség azonos pulzus növekedésre) ott lesz az anaerob küszöböd. Érzésre is meg lehet mondani, ha gyakorlott sportoló vagy. Aerob alap építésével ki lehet tolni, hogy magasabb sebességen alacsonyabb legyen a pulzus. A küszöböt is ki lehet tolni, ahhoz meg anaerob, erőállóképességi edzés kell.