A Fab Four technika reagálóképes e-mailek létrehozására média lekérdezések nélkül

Azt hiszem, új módot találtam az adaptív e-mailek létrehozására, média kérdése nélkül. A megoldás magában foglalja a CSS calc () függvényt, valamint a három szélesség , min szélesség és max szélesség tulajdonságot.

Vagy ahogy szeretem mindet együtt hívni: a Fab Négyet (CSS-ben).

A probléma

Reszponzív e-mailek készítése nehéz, különösen azért, mert a mobil e-mail kliensek (például a Gmail, a Yahoo vagy az Outlook.com) nem támogatják a média lekérdezéseket. A hibrid megközelítés, a Gmail első stratégiája vagy a médiakérdések nélküli válaszadó e-mail nagyszerű módja a helyzethez való alkalmazkodásnak.

Ez utóbbi megközelítés volt eddig a kedvencem. A nagy ötlet az, hogy oszlopok legyenek iv> s rögzített szélességgel, igazítva a „display: inline- block” sorhoz . Ha egy képernyőn már nem lehet két blokk egymás mellett, akkor természetesen egymás alatt fognak áramlani. De ezzel mindig is gondom volt.

Miután az összes blokk egymásra került, nem veszik át az e-mail teljes szélességét.

Régóta keresem a probléma megoldásának módjait. A Flexbox nagyszerű versenyző, de sajnos a Flexbox e-mailben történő támogatása óriási.

Egy megoldás

Szélesség , min-szélesség és max-szélesség megjegyzése

A calc () függvény tetején az általam talált megoldás magában foglalja ezt a három CSS tulajdonságot. A működésének teljes megértése érdekében íme egy emlékeztető arról, hogy a szélesség , a min szélesség és a maximális szélesség hogyan viselkednek együttes használat esetén (amint azt a francia front-end fejlesztő munkatársa, Raphaël Goetter világosan összefoglalta).

  • Ha a szélesség értéke nagyobb, mint a maximális szélesség értéke, akkor a maximális szélesség nyer.
  • Ha a min szélesség értéke nagyobb, mint a szélesség vagy a max szélesség értéke, akkor a min szélesség nyer.

Meg tudja tippelni, hogy mekkora lenne a következő stílusú doboz szélessége?

.box { width:320px; min-width:480px; max-width:160px;}

(Válasz: a doboz 480 képpont széles lenne.)

A calc () és a mágikus képlet bemutatása

Minden további nélkül itt van egy példa a Fab Four-ra, amely két oszlopot hoz létre, amelyek egymásra rakódnak és 480px alá nőnek.

.block { display:inline-block; min-width:50%; max-width:100%; width:calc((480px — 100%) * 480);}

Bontjuk le minden szélességi tulajdonságra.

min-width:50%;

A min-width tulajdonság az oszlopszélességünket határozza meg az asztali verziónknak. Megváltoztathatjuk ezt az értéket további oszlopok hozzáadásához (például 25% négy oszlopos elrendezésnél), vagy fix pixelszélességű oszlopokat állíthatunk be.

max-width:100%;

A max-width tulajdonság az oszlopszélességünket határozza meg, amit mobil verziónak nevezhetnénk. 100% -ban minden oszlop megnő és alkalmazkodik a szülőtartályuk teljes szélességéhez. Megváltoztathatjuk ezt az értéket, hogy oszlopokat tartsunk a mobilon (például 50% két oszlopos elrendezés esetén).

width:calc((480px — 100%) * 480);

A calc () függvénynek köszönhetően a szélesség tulajdonság az, ahol a varázslat megtörténik. A 480 érték megegyezik a kívánt töréspont értékünkkel. A 100% megfelel az oszlopok szülőtartályának szélességének. Ennek a számításnak az a célja, hogy olyan értéket hozzon létre, amely nagyobb, mint a maximális szélességünk, vagy kisebb, mint a min-szélességünk , így e tulajdonságok egyikét alkalmazzák helyette.

Íme két példa.

500 képpontos szülő esetén a számított szélesség -9600 képpont. Kisebb, mint a min-szélesség. Tehát az 50% -os min-szélesség nyer. Így két oszlopos elrendezéssel rendelkezünk.

400 képpontos szülő esetén a számított szélesség 38400 képpont. Nagyobb, mint a min-szélesség, de a max-szélesség kisebb. Tehát a 100% -os maximális szélesség nyer. Így egy oszlopos elrendezéssel rendelkezünk.

Demó

Itt van egy bemutató, amire ez a technika képes.

A teljes bemutatót itt (vagy a Litmus Builder vagy a CodePen oldalon) láthatja.

És itt van két képernyőkép erről a bemutatóról a Gmailben, az asztali webmailen és az iOS mobilalkalmazásában. Ugyanaz a kód, más a megjelenítés.

Ebben a bemutatóban bemutattam néhány példát különböző rácsokra (két, három, négy oszloppal). Az első rács a képekkel úgy van kialakítva, hogy az asztali számítógép négy oszlopától a mobilon két oszlopig menjen. A többi rács teljes szélességben növekszik a mobilon.

Figyelje meg azt is, hogyan változik a cím az asztali gép balra igazított helyzetéből a mobil középpontjába. Ezt úgy érhetjük el, hogy a címnek fix 190px szélességet és „ margin: 0 auto; ”Középre. Az asztalon a cím szülőtárolójának min 190 szélessége van, ezért az embléma a bal oldalon marad. Mobilon a szülőtároló teljes szélességben növekszik, így az embléma középre kerül.

Ennek a technikának nagy szempontja, hogy mivel minden a rács szülő szélességén alapul, az e-mail akár asztali webmailen is képes alkalmazkodni. Például az Outlook.com webhelyen, függetlenül attól, hogy az olvasási ablaktáblát alul vagy jobb oldalon választotta-e, az e-mail helyesen reagál az olvasási panel szélességére. Ezt lehetetlen megtenni a média lekérdezéseivel.

Támogatás

In browsers, calc() is well supported since IE9. Turns out, calc() also has a pretty good support in email clients. It works in Apple Mail (on iOS and OS X), Thunderbird, Outlook (iOS and Android apps), Gmail (webmail, iOS and Android apps), AOL (webmail), and the old Outlook.com (still present in Europe).

The old Outlook.com

Outlook.com has one small quirk, though. The webmail will filter every property with a calc() that includes any parenthesis. This means that “calc(480px - 100%)” is supported, but “calc((480px - 100%) * 480)” is not. Since my initial formula involves parenthesis, we need to refactor it to avoid parenthesis. So the formula to support the old Outlook.com looks like this.

width:calc(480px * 480 — 100% * 480);

Unsupported clients

Of course, calc() isn’t supported in old email clients like Lotus Notes, or the latest Outlook for Windows (using Word’s HTML rendering engine). It also won’t work on Outlook Web App (both Office 365 and the new Outlook.com) and Yahoo (webmail, iOS and Android apps). These two will strip out any property involving a calc().

Fallbacks

In these cases, I would suggest duplicating all involved properties with fixed width values for clients that don’t support calc(). In order to hide The Fab Four from those clients, I advise to use calc() functions, even if it’s not technically useful. Our first example would look like the following.

.block { display:inline-block; min-width:240px; width:50%; max-width:100%; min-width:calc(50%); width:calc(480px * 480 — 100% * 480);}

Outlook Web App

However, Outlook Web App (both Office 365 and the new Outlook.com) has one more quirk of its own. When a calc() function contains a multiplication (with the ‘*’ character), the new Outlook.com and Office 365 will remove the whole inline style attribute corresponding. This means we need to calculate the multiplications by hand and only keep the resulting substraction. Here’s what the final calculation looks like for a 480px breakpoint.

width:calc(230400px — 48000%);

WebKit Prefixes

Older versions of Android (before Android 5.0) or iOS (before iOS 7) require -webkit- prefixes in order to work. Our final version looks like the following.

.block { display:inline-block; min-width:240px; width:50%; max-width:100%; min-width:-webkit-calc(50%); min-width:calc(50%); width:-webkit-calc(230400px — 48000%); width:calc(230400px — 48000%);}

Shortcomings and final thoughts

Like anything in the email development world, the Fab Four technique isn’t perfect. Here are a few limitations that I can think of:

  • It won’t work on Yahoo. The desktop version of its webmail supports media queries, though. So we could improve things a bit by making a mobile first version of our email, and then enhancing it on desktop with media queries.
  • You can only set one breakpoint. This might not be such a problem for emails though, as designs rarely go beyond 600px on desktop and don’t require more than one breakpoint to adapt on mobile.
  • You can only diminish the number of columns from a desktop version to a mobile version. While this rarely happens, you couldn’t go from a four columns layout on mobile to a single column layout on desktop.
  • The final version of the calculation (to support the old Outlook.com and degrade gracefully on the new one) is hard to read. Using a preprocessor and a mixin to generate all the required properties could be more than helpful.

I still think that this technique will come in very handy in a lot of cases, especially for Gmail optimizations. I’m sure there is also use cases for websites (like widgets, ads, …).

And I can’t wait to see what this will inspire you to create.