Válaszkész webhely létrehozása egy hét alatt: média lekérdezések (4. rész)

Tartalom

• 01. Média lekérdezések hozzáadása
• 02. A média lekérdezésének anatómiája
• 03. Még egy dolog…
• 04. Töréspontok kiválasztása
• 05. Miniatűrjeink beállítása
• 06. Nem csak a szélesség

• Szükséges tudás: Közbenső CSS és HTML
• Igényel: Szövegszerkesztő, modern böngésző, grafikus szoftver
• Projekt idő: 1 óra (összesen 5 óra)
• Támogatási fájl

A CSS specifikáció viszonylag új része, a média lekérdezések kétségtelenül a legizgalmasabb szempontok a reszponzív web tervezésben, és a további kísérletezésre megérett terület.

Elfogadva az adaptív elrendezések szükségességét, néhányan a média lekérdezéseket tekintették eszköznek az adaptív elrendezések utólagos felszerelésére a meglévő rögzített szélességű helyeken. Azok között, akik alkalmazkodtak az érzékeny elrendezéshez, sokan tették ezt az asztal szempontjából, elrejtve a tartalmat és a szolgáltatásokat, ahogy a nézetablak szűkül.

A bemutató során alternatív, először mobil megközelítést választottunk. Most, amikor média lekérdezéseket szeretnénk bevonni, elgondolkodhatunk hozzátéve jellemzői a képernyőn megjelenő ingatlanok növekedésével, biztonságban abban a tudatban, hogy a webhelyünket alátámasztó jelölés és kialakítás tekintélyes kiindulópontot nyújt.

Ma túllépünk mintaportfóliónkon és elkészítjük a weboldalunkhoz szükséges egyedi oldalakat. Ennek során meglátjuk, hogyan épülnek fel a média lekérdezések, és azokat valóban reagálva valósítjuk meg.

01. Média lekérdezések hozzáadása

Miután a mintaportfóliónk összetevői teljesek és bármilyen elrendezés határain kívül dolgoznak, itt az ideje, hogy áthelyezzük őket a webhelyünket alkotó különböző oldalakra.

Kezdjük a honlapunkkal. Az asztalra orientált kialakításból láthatjuk, hogy szélesebb nézetablakokban az elrendezésnek a következőképpen kell megjelennie:

Tervezésünkből méréseket véve a következőképpen írhatjuk le a dokumentumterületet a CSS-ben:

.document {
párnázás: 0 5%;
}
.main {
szélesség: 74,242424242424%; / * 784/1056 * /
balra lebeg;
}
.kiegészítő {
szélesség: 22,727272727273%; / * 240/1056 * /
úszó: jobbra;
}

Amint az oktatóanyag második részében megtudtuk, a következő képletet használjuk az oszlopok százalékos szélességének kiszámításához:

(cél / kontextus) * 100 = eredmény

Amikor átméretezzük a böngészőnket, látni fogjuk, hogy az asztali elrendezésünk a legkisebb méretű képernyőtől a legnagyobbig terjed. Természetesen kis méretnél az oszlopok túl keskenyek és a vonalvezetés olyan rövid, hogy a tartalom nehezen olvasható. Csak akkor akarjuk ezt az elrendezést, ha elegendő hely áll rendelkezésre a működéséhez.

Ide érkeznek a média lekérdezések. Feltéve, hogy ennek az elrendezésnek csak akkor kell érvényesülnie, ha a böngésző szélesebb, mint 768 képpont, a következő CSS-t adhatjuk hozzá:

.document {
párnázás: 0 5%;
}
@media képernyő és (min-width: 768px) {
.main {
szélesség: 74,242424242424%; / * 784/1056 * /
balra lebeg;
}
.kiegészítő {
szélesség: 22,727272727273%; / * 240/1056 * /
úszó: jobbra;
}
}

Most, amikor a nézetablak keskenyebb, mint 768 képpont, a média lekérdezésen belül mindent figyelmen kívül hagynak. Minden olyan böngésző figyelmen kívül hagyja, amely nem támogatja a média lekérdezéseket is.

02. A média lekérdezésének anatómiája

Hogy megértsük, mi történik itt, nézzük meg, hogyan épül fel a média lekérdezés. Két részre oszthatjuk:

• @media képernyő: A média lekérdezés első része a média típus. Akkor ismerheti fel ezt a szintaxist, ha valaha is felvett nyomtatási stílusokat a CSS-be. A típus nevét felismerheti a média attribútum a link> elem. Ennek oka, hogy mindkettő elfogadja a CSS 2.1 specifikációban található jóváhagyott médiatípus-készletet.
• (min-szélesség: 768 képpont): A második rész a lekérdezés. Ide tartozik a funkció lekérdezendő (ebben az esetben a nézetablak minimális szélessége) és a megfelelő érték tesztelni (768px).

Amikor adaptív webdesignról beszélünk, hajlamosak vagyunk a szélességre összpontosítani, de vannak más funkciók is, amelyeket tesztelhetünk:

• (min- | max-) szélesség és (min- | max) magasság: Ez lehetővé teszi számunkra, hogy lekérdezzük a nézet szélességét és magasságát (azaz a böngészőablakot).
• (min- | max-) eszközszélesség és (min- | max) eszközmagasság: Ezek lehetővé teszik, hogy lekérdezzük a teljes kijelző szélességét. Tapasztalataim szerint általában ésszerűbb az elrendezéseket a nézetablakra alapozni, nem pedig a kijelzőre.
• irányultság: Azonnal gondolkodhat itt a lehetőségeken; gondoljon olyan alkalmazásokra, amelyek a telefon tájolása alapján különböző tartalmat mutatnak - ugyanez lehetséges az interneten is.
• (min- | max-) képarány: Ez lehetővé teszi számunkra, hogy az elrendezéseket a böngészőablak aránya alapján adaptáljuk ...
• (min- | max) eszköz-képarány: … És ez lehetővé teszi számunkra, hogy ugyanezt tegyük az eszköz képaránya alapján is. Owen Gregory egy csodálatos cikket írt tavaly, amely azt vizsgálta, hogy miként használhatjuk ezt a lekérdezést arra, hogy a terveinket azokhoz az eszközökhöz kössük, amelyeken megjelennek.
• (min- | max) monokróm: Azt is tesztelhetjük, hogy egy eszköz monokróm kijelzővel rendelkezik-e vagy sem. Képzelje el, mennyire hasznos lenne ez, ha az Amazon e-ink Kindle készülékei nem hazudnának, és a képernyőket színesnek jelentenék!

Lekérdezésünk utolsó része valószínűleg a leghasznosabb. Használva és, egy lekérdezésben több funkciót is tesztelhetünk. Például:

@media képernyő és (min-width: 768px) és (orientation: landscape) {
...
}

Mint látható, a média lekérdezések segíthetnek számunkra meglehetősen meggyőző tapasztalatok építésében - és csak a felszínt érintettem. Ha könnyű lefekvés előtt szeretne olvasni, akkor rosszabbul járhat, mint elolvasni a W3C média lekérdezés specifikációját, amely leírja az összes olyan tulajdonságot, amelyre tesztelhetjük.

03. Még egy dolog…

Annak ellenére, hogy a média lekérdezéseket belefoglaltuk a CSS-be, ha mobil eszközön tekintjük meg a webhelyünket, akkor észreveszi, hogy webhelyünket továbbra is úgy rendereljük, mintha a kijelző szélesebb lenne, mint 768 képpont.

Hogy megértsük, miért történik ez, egy rövid történelemórát kell tartanunk.

Amikor az eredeti iPhone-t 2007-ben bejelentették, az egyik legnagyobb eladási pontja az „igazi web” böngészésének képessége volt, még akkor is, ha ez fix szélességű, asztali orientált webhelyeket jelentett, amelyeket le kellett nyomni, hogy elférjenek a kis képernyőn. Az iPhone ezt úgy tudta megtenni, hogy a kijelzőjét 980 képpontos szélességűnek jelentette, mielőtt a weboldalakat kicsinyítette, hogy illeszkedjen a 320 képpontos képernyőhöz.

De az iPhone-t még a adaptív tervezés megjelenése előtt mutatták be. Most, hogy a szerzők mobilra tervezett webhelyeket terveznek, ez a funkció kevésbé hasznos. Szerencsére az Apple tartalmazott egy módszert ennek a viselkedésnek a megkerülésére, és mióta más gyártók átvették, szinte de facto alapértelmezett. Ez egyszerűen magában foglalja egy kislemez hozzáadását meta elem a jelölőnkhöz:

meta név = "nézetablak" content = "kezdeti méretarány = 1,0, szélesség = eszközszélesség" />

Ez azt mondja a nézetablakot ismerő böngészőknek, hogy egy webhelyet nem szabad kicsinyíteni, és hogy a böngészőablak szélességét ugyanúgy kell kezelni, mint az eszköz teljes szélességét. Miután hozzáadtuk ezt a sort, weboldalunk a tervezett elrendezéssel jelenik meg:

04. Töréspontok kiválasztása

Térjünk vissza média lekérdezésünkre:

@media képernyő és (min-width: 768px) {
...
}

Azokat az értékeket, amelyeknél az elrendezés alkalmazkodik, általában töréspontoknak nevezzük. Ha emlékszel, a második részben azt mondtam, hogy a pixelek használata a nem reagáló gondolkodás jelzését jelenti, mégis itt a 768 képpontot választottam, valószínűleg azért, mert egy ismert eszköz szélessége.

Ahelyett, hogy a népszerű eszközök jellemzői alapján választanánk a töréspontokat, hatékonyabb lehet a tartalmunkból származtatott értékeket megnézni, például az olvasás kényelmes vonalvezetését vagy a kép maximális méretét.

Mivel típusunkat ems használatával méretezzük, ésszerűnek tűnik, ha média lekérdezéseink ems-t is használnak. Valójában ennek további előnye van. Amikor a felhasználó átméretezi a szöveget a böngészőben, az oldalak alkalmazkodnak a kisebb töréspontok használatához. Weboldalunk nem csak a nézetablak, hanem a betűméret alapján is alkalmazkodni fog. Valójában csak akkor láttam meg, hogy Jeremy Keith bemutatja az em-alapú média lekérdezéseit, hogy ezek milyen hatalmasak lehetnek.

Noha a tervünk némi jelzést adhat a lehetséges töréspontokról, gyakran a kísérletezéssel lehet a legjobb választani. A böngészőablak szélességének beállításával úgy döntöttem, hogy a 800px jó szélesség, amelynél összetettebb elrendezésre lehet váltani.

Hogyan fejezzük ki mégis 800px-t az ems-ben? Ismét használhatjuk a képletünket, de mi a kontextus? A média lekérdezések ems kiszámításakor a kontextus mindig a böngésző alapértelmezett betűmérete függetlenül attól, hogy ezt az értéket felülírták-e a CSS-ben. Ez az alapértelmezés általában 16 képpont, amely a következőket adja meg:

800 / 16 = 50

Most már így frissíthetjük a média lekérdezésünket:

@media képernyő és (min-width: 50em) {/ * 800px * /
...
}

05. Miniatűrjeink beállítása

Emlékezhet arra, hogy a 2. részben a bélyegképeket reagálásra terveztük. Amint azonban ezeken a bélyegképeken lévő képek elérik teljes szélességüket, minden kép jobb oldalán megjelenik egy fehér terület. A média lekérdezések ismét lehetővé teszik, hogy ezt kijavítsuk.

Itt található az eredeti CSS:

ol.media li.media-item {
háttérszín: #fff;
margó: 0 4,16666666667% 4,166666666667% 0;
szélesség: 47,91666666667%;
balra lebeg;
}
ol.media li.media-item: n-dik gyermek (2n) {
jobb-jobb: 0;
}

Ez a szóköz akkor jelenik meg, amikor a böngésző szélesebbé válik, mint az 560 képpont.Kiválasztjuk ezt az értéket, amelyen felcserélhetjük a soronként három miniatűr megjelenítését. Ezt a következő CSS hozzáadásával tehetjük meg:

@media képernyő és (min-width: 35em) {
.media-item {
szélesség: 30,612244897959%; / * 240/784 * /
margó: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: n -edik gyermek (3n) {
jobb-jobb: 0;
}
}

Ne feledje, hogy nem kell átírnunk a média lekérdezésen belül az indexképhez szükséges összes stílust, csak azokat a részeket, amelyeket adaptálni akarunk.

A böngészőben ezt a változást megtekintve észreveheti, hogy minden második indexkép jobb oldalán nincs margó. Ennek oka, hogy a következő CSS-szabály továbbra is aktív marad:

ol.media li.media-item: n-dik gyermek (2n) {
jobb-jobb: 0;
}

Módosítanunk kell a CSS-t a média lekérdezésünkön az érték visszaállításához:

@media képernyő és (min-width: 35em) {
.media-item {
szélesség: 30,612244897959%; / * 240/784 * /
margó: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: n -edik gyermek (2n) {
jobb szél: 4,081632653061%;
}
.media-item: n -edik gyermek (3n) {
jobb-jobb: 0;
}
}

Média lekérdezések készítésekor mindig ügyeljen az ilyen öröklési kérdésekre.

06. Nem csak a szélesség

Fontos elgondolkodni a média lekérdezéseken nemcsak a szélesség, hanem más változók szempontjából is. Például a médiaelem oldalunkon lévő videó részben el van rejtve, ha a nézetablak magassága csökken. Megvan a technológia:

.media-object-wrapper {
aljzat: 56,25%;
szélesség: 100%;
magasság: 0;
pozíció: rokon;
}
@media képernyő és (max-magasság: 35em) és (tájolás: fekvő) {/ * 560px * /
.media-object-wrapper {
szélesség: 60%;
aljzat: 33,75%;
}
}

Még egy orientációs lekérdezést is felvettem, hogy tovább finomítsam ezt a viselkedést.

Hasonló megközelítést alkalmazhatunk a tervezés többi részében is, ha átcseréljük a fejléc nagyobb változatát, és ha a szabad terület rendelkezésre áll, a navigációs linkeket az oldal tetejére helyezzük.

• Tekintse meg érzékeny honlapunkat
• Tekintse meg érzékeny médiaoldalunkat

És itt van! Létrehoztunk egy érzékeny weboldalt - és egy napra van szükségünk! Nos, nem egészen. A rugalmas elrendezések, képek és média lekérdezések csak a kezdet az adaptív tervezési folyamatnak.

Holnap: A bemutató utolsó részében túllépünk az adaptív webtervezésen, és megvizsgáljuk, hogyan építhetünk valóban reagáló weboldalakat.

Paul az angliai Brightonban működő interakciótervező. A legboldogabb, ha egyszerű, mégis vonzó interfészeket készít, amelyek őshonosak az interneten.