Sähköpostin HTML ei ole web-HTML:ää. Tämä on ensimmäinen oppi, jonka jokainen kehittäjä oppii kovalla tavalla, yleensä pitkien tuntien jälkeen kauniiden sähköpostipohjien rakentamisen jälkeen modernilla CSS:llä, testisähköpostin lähettämisen jälkeen omaan postilaatikkoon ja kun he huomaavat, että se näyttää täydelliseltä yhdessä ohjelmassa ja katastrofaalisesti rikkinäiseltä toisessa. Toinen oppi, joka usein saapuu muutaman minuutin kuluttua ensimmäisestä, on, että sähköpostiohjain, joka vastaa pahimmasta renderoinnista, on lähes aina Outlook, ja Outlookilla on riittävän suuri markkinaosuus, että sen rajoitusten huomiotta jättäminen ei ole vaihtoehto. Kolmas oppi, joka istuu viikkojen ja kuukausien kuluessa, on, että sähköpostin HTML-yhteensopivuus ei ole ongelma, joka ratkaistaan kerran ja pysyy ratkaisuna. Se on jatkuva rajoitus, joka muokkaa jokaista suunnittelupäätöstä ja jokaista koodiriviä niin kauan kuin sähköpostiohjelma toimii.
Sähköpostin renderointiepäjohdonmukaisuuden juurisyy on, että sähköpostiohjaimet eivät käytä selainrenderointimoottoreja. Tai pikemminkin jotkut käyttävät ja jotkut eivät, ja ne, jotka eivät käytä, käyttävät renderointimoottoreita, joita ei koskaan suunniteltu modernille HTML:lle ja CSS:lle. Gmail poistaa eniten CSS:ää sähköpostin pääotsikoista ja tukee vain sisäkkäisten tyylien osajoukkoa. Outlook käyttää Microsoft Wordin renderointimoottoreja HTML:lle, mikä on suunnilleen sama kuin ruuvin käyttäminen sopan syömiseen: sillä on teknisesti jonkinlainen kyky, mutta tulokset ovat kaukana siitä, mitä työkalun ulkonäkö ehdottaa. Apple Mail käyttää WebKitia ja renderöi useimpia moderneja CSS:iä oikein, mikä tekee siitä helpoimman tuen ja vaarallisimman testausohjelman, koska onnistuminen Apple Mailissa luo väärää itseluottamusta yhteensopivuudesta kaikkialla muualla.
HTML-generaattorin API ratkaisee tämän ongelman luontitasolla eikä testaamisen tasolla. Sen sijaan, että rakentaisit sähköpostipohjaa modernilla tekniikalla ja sitten virheidensä korjaamisella asiakkaiden välillä, dokumenttipääte luo sähköpostin HTML:n, joka on luonnostaan yhteensopiva kaikkien tärkeimpien sähköpostiohjajien rajoituksista. Tulostus käyttää taulukkopohjaisilla ulkoasuja, sisäkkäisiä tyylejä ja rajoitettua CSS-sanakirjaa, joka renderöityy johdonmukaisesti Gmailin, Outlookin, Apple Mailin, Yahoo Mailin ja kymmenten pienempien asiakkaiden välillä, jotka yhdessä edustavat loput markkinoista. Yhteensopivuus on rakennettu tuottoon, ei asennettu jälkeenpäin.
📄PDF-kirjageneraattori
Luo PDF-kirjoja ja -dokumentteja AI:lla. Valitse malleista, mukauta asetteluja ja vie useissa muodoissa.
✓ AI-luonti✓ Kirjamallit✓ Useita muotoja✓ Joukkovienti
Web siirtyi pois taulukkopohjaisista asetteluista 2000-luvun puolivälissä, ja hyvästä syystä. CSS flexbox ja grid tarjoavat joustavampia, semantiikkaa paremmin noudattavia ja paremmin ylläpidettäviä asetteluvaihtoehtoja verkkosivuille. Mutta sähköpostiohjaimet, erityisesti Outlook, eivät koskaan saavuttaneet tätä siirtymää. Outlookin Word-pohjainen renderointimoottori käsittelee HTML-taulukoita luotettavasti, koska taulukot ovat Word-pääkyvykkyyden ydin. Se käsittelee CSS-flexboxia ja -ruudukkoa ei ollenkaan, koska Wordilla ei ole käsitystä näistä asettelutyyppejä. Koska Outlook edustaa merkittävää osuutta liiketoiminnan sähköpostinaukisuista, erityisesti yritys- ja B2B-yhteyksissä, kaikki sähköpostipohjat, joiden on saavutettava liiketoimintakatsaus, on käytettävä taulukkopohjaisilla asetteluilla tai hyväksynneet, että merkittävä prosenttiosuus vastaanottajista näkee rikkinäisen sotkun.
Taulukkopohjaiset sähköpostin asettelut eivät ole yksinkertaisesti sisäkkäisyden, solun kokoon, välilyönnin ja kuvan käsittelyn erityiseen lähestymiseen, joissa otetaan huomioon jokaisen sähköpostiohjaaimen taulukkorenderöinnin omituisuudet. Gmail kutistaa taulukkosolujaeri tavalla kuin Outlook. Yahoo Mail käsittelee taulukon leveysmääritteitä eri tavalla kuin Apple Mail. Täytteen ja marginaalien käyttäytyminen taulukkosoluissa vaihtelee asiakkaiden välillä tavalla, joka ei noudata mitään julkaistua spesifikaatiota, koska useimmat sähköpostiohjaimet toteuttavat taulukkorenderöinnin omalla tulkinnalla ilman verkkostandardi-yhteensopivuutta.
Dokumenttipääte luo taulukon rakenteita, jotka ottavat huomioon nämä ristiinasiakaiden vaihtelut. Saraakkeiden leveydet määritellään sekä prosentteina että pikseliyksiköissä asiakkaiden, jotka jättävät yhden tai toisen huomiotta. Solujen välilyönti käyttää sekä cellpadding-attribuutteja että sisäkkäisiä täytteen tyylejä, koska eri asiakkaat kunnioittavat erilaisia mekanismeja. Kuvan tunnisteet sisältävät eksplisiittiset leveys- ja korkeus-attribuutit, näyttöä esty tyyleissä ja raja-nolla-deklaraatioissa, jotka estävät renderointejä, joita useimmat asiakkaat aiheuttavat, kun kuvia sijoitetaan taulukkosoluihin ilman näitä erityiskäsittelyjä.
Tuloksena on sähköpostin HTML, jonka kehittäjä tunnistaa teknisesti vanhentuneeksi verkko-standardien mukaan, mutta joka renderoityy pikselitarkalla johdonmukaisuudella sähköpostiohjajien välillä, joita kohdistava yleisö tosiasiassa käyttää. Tämä on sähköpostikehityksen perustavanlaatuinen kompromissi: teknisesti oikea lähestymistapa (moderni CSS, semantiikka HTML, reagoiva suunnittelu mediakyselyiden kautta) tuottaa epäyhtenäisiä tuloksia, kun taas teknisesti vanhentunut lähestymistapa (taulukot, sisäkkäiset tyylit, kiinteät leveydet ja juoksevat vaihtoehdot) tuottaa luotettavia tuloksia. API tekee tämän kompromissin automaattisesti, joten kehittäjän ei tarvitse sisäistää kaksikymmentä vuotta sähköpostin renderointiomituuksien tietoa tuottaakseen yhteensopivat mallit.
Gmailin CSS-käsittely on yksittäin suurin rajoitus sähköpostipohjien suunnittelussa. Gmail poistaa kaiken CSS:n dokumentin pääotsikosta, poistaa kaikki luokka- ja tunnistevalitsimet kehosta ja tukee vain sisäkkäisiä tyylejä, jotka sovelletaan suoraan yksittäisiin HTML-elementteihin. Tämä tarkoittaa, että jokainen visuaalinen ominaisuus, jokainen väri, jokainen fontin koko, jokainen marginaali, jokainen täyte-arvo, on määriteltävä sisäkkäisenä tyyli-attribuuttina elementille, johon se koskee. Kaskaadia ei ole, perintöä ei ole (lukuun ottamatta harvoja poikkeuksia), ja kykyä määrittää tyylit kerran ja soveltaa niitä useisiin elementteihin jaetun luokkanimeen ei ole.
Kehittäjille, joilla on perehtyneisyys verkko-CSS:ään, tämä rajoitus on lähes pilaillen rajoittava. Verkkosivulla voidaan määrittää otsikon tyyli kerran tyylisivulla ja soveltaa sitä jokaiseen sivun otsikkoon. Sähköpostipohjassa on sovellettava samat otsikko-tyylit jokaiselle otsikolla erikseen sisäkkäisenä tyyli-attribuuttina, jotka toistavat samat deklaraatiot jokaisessa elementissa. Pohjassa, jossa on kaksikymmentä tyylinnettyä elementtiä, voi olla kaksikymmentä kopiota samoista fontin perheestä, fontin koosta ja värin deklaraatioista. Tämä toisto on sanallisesti raskas, ylläpidon-vihamielinen ja tuntuu väärin kenellä tahansa webkehityskoulutuksella. Se on myös ainoa lähestymistapa, joka toimii luotettavasti Gmailissa.
Dokumenttipääte käsittelee tämän sisäkkäisen sisällyttämisen automaattisesti. Käyttäjä kuvaa sähköpostin sisällön ja tyylinvalintasuhteet syötteessä, ja API luo tuloksen, jossa jokainen relevantti tyyli sovelletaan sisäkkäisesti asianomaisiin elementteihin. Käyttäjän ei tarvitse koskaan kopioida tyylien deklaraatioita manuaalisesti kymmeniä elementteja, ei tarvitse huolehtia siitä, mitkä ominaisuudet Gmail tukee ja mitkä se poistaa, ja ei tarvitse ylläpitää paisunutta sisäkkäisen tyylin merkkausta, jota sähköpostin yhteensopivuus vaatii. Luontiprosessi omaksuu vaivan ja omituuksien tietoa tuottaakseen tuotteen, jonka käyttäjä voi lähettää luottamuksella.
Gmailin tyylin poiston lisäksi API käsittelee myös erityisiä tyyliominaisuuksia, joita yksittäiset asiakkaat tulkitsevat eri tavalla. Rajan sädettä käytetään Apple Mailissa ja joissa webmail-asiakkaissa, mutta Outlook jättää huomiotta. Luodut mallit käyttävät rajan sädettä, jossa se parantaa suunnittelua tukevissa asiakkaissa, samalla kun varmistetaan, että asettelu pysyy yhtenäisenä asiakkaissa, jotka eivät renderöi pyöristettyjä kulmia. Tämä arvoisa heikkenemisen lähestymistapa, jossa malli näyttää hyvältä kykenevissä asiakkaissa ja hyväksyttävältä rajoitetuissa, sovelletaan järjestelmällisesti kaikkiin ominaisuuksiin, joissa asiakkaan tuki vaihtelee.
Responsiivinen verkkosuunnittelu perustuu mediakyselyihin, jotka muokkaavat asetteluja näytön koon perusteella. Sähköpostin responsiivinen suunnittelu on tarkoitus toimia samalla tavalla, ja se tekee joissa asiakkaissa. Apple Mail tukee mediakyselyitä täysin. Alkuperäinen iOS-sähköpostisovellus tukee niitä. Joissa webmail-asiakkaissa niitä tuetaan, kun niitä käytetään mobiiliselaimella. Ja Gmail, joka edustaa suurinta yksittäistä sähköpostiohjelmaa äänillä, poistaa kaikki mediakyselyt dokumentin pääotsikoista yhdessä muun ei-sisäkkäisen CSS:n kanssa. Sähköpostipohja, joka perustuu mediakyselyihin mobiili-asettelussaan, toimii kauniisti iPhoneissa käyttäen Apple Mailia ja menee täysin rikki Gmail-käyttäjille samoissa laitteissa.
Dokumenttipääte käsittelee responsiivista sähköpostia tekniikalla, jota kutsutaan joskus "pesuksi" tai "hybridi" asetteluksi, joka saavuttaa reagoivan käyttäytymisen ilman mediakyselyistä riippuvuutta. Tämä lähestymistapa käyttää taulukon leveys-attribuuttien, max-width-rajoitusten ja juoksevien leveys-laskelmien yhdistelmää, joka mahdollistaa sähköpostin asettelun sopeutumisen erilaisiin näytön leveyksiin käyttäen vain sisäkkäisiä tyylejä ja HTML-attribuutteja. Tekniikka on rajoitetumpi kuin mediakyselyyn perustuva reagoivuus, mutta se toimii johdonmukaisesti kaikissa tärkeimmissä asiakkaissa, mukaan lukien Gmail, mikä on ratkaisevan tärkeä etu.
Käytännössä hybridi-lähestymistapa tuottaa sähköposteja, jotka näyttävät sisällön monisarakkeisissa asetteluissa leveillä näytöillä ja pinoutuvat yksittäisen sarakkeen asetteluihin kapeilla näytöillä, mikä kattaa tärkeimmän reagoivan käyttäytymisen suurimmalle osalle sähköpostin kuvioita. Monimutkaisemmat reagoivat vaatimukset, kuten sisällön osioiden uudelleenjärjestely mobiili- ja pöytäkoneen välillä tai eri kuvien näyttö eri näytön kokoon, vaativat mediakyselyitä ja siksi uhraavat Gmailin yhteensopivuuden. API oletusarvo hybridi-lähestymistapaan, joka maksimoi yhteensopivuuden, tuottaa reagoivaa käyttäytymistä jokaisessa asiakkaassa, joka on tärkeä, eikä täydellinen reagoiva joustavuus vain joissa niistä.
Luodut mallit sisältävät mediakyselyt parannuskerroksena asiakkaille, jotka tukevat niitä, lisäten kiteytyneet typografia-säädöt ja välilyönnin optimoinnit, jotka parantavat kokemusta Apple Mailissa ja iOS:ssä ilman vaikutusta perustutkimukseen asiakkaissa, jotka poistavat ne. Tämä kerrostunut lähestymistapa, hybridi-asettelu yleiselle reagoivuudelle ja mediakyselyt parannuksille reagoivuudelle, edustaa nykyisten parhaiden käytäntöjen sähköpostikehityksessä ja otetaan automaattisesti jokaisessa API:n luomassa mallissa.
Työnkulku sähköpostipohjien luomiselle HTML-generaattori API:n kautta peilaa aloitussivun työnkulkua yhdellä kriittisellä erolla: tuotanto on optimoitu sähköpostiohjajien renderoinnille, ei selainrenderöinnille. Käyttäjä toimittaa kuvauksen sähköpostin sisällöstä joko strukturoidussa JSON:ssa (lohko-päätepisteen käyttäminen) tai luonnollisen kielen kuvauksessa (dokumenttipäätepisteen käyttäminen). API luo HTML-pohjaa kaikkien edellä kuvattujen yhteensopivuusseikkojen kanssa, joita soveltuu automaattisesti.
Luodun pohjaa voidaan esikatsella verkkoselaimessa, joka näyttää pöytäkoneen renderöinnin, ja sähköpostin testaamisen työkaluissa, jotka simuloivat tiettyjen asiakkaiden renderöintikäyttäytymistä. Vaikka selaimen esikatselu antaa yleisen käsityksen pohjasta näkymyksestä, sähköpostin testaustyökalut ovat olennaiset Outlookin renderoinnin tarkistamiseksi, koska Outlookin Word-moottori tuottaa tuloksia, joita mikään selain ei voi kopioida. API:n tuotanto on suunniteltu kulkemaan sähköpostin testaustyökalun varmennuksen kautta kaikissa tärkeimmissa asiakkaissa, mikä vähentää testaus vaihetta pitkistä ristiinasiakas-virheistä nopeaan varmennukseen, joka vahvistaa, mitä generaattori jo varmistaa.
Luodun pohjaa lähettäminen vaatii sähköpostipalveluntarjoajaa (ESP) tai suoraa SMTP-yhteyttä. HTML-sisältö sijoitetaan sähköpostin runkoon käyttäjän infrastruktuurin antaman lähettämisen mekanismin kautta. Suuret ESP:t, kuten Mailchimp, SendGrid, Amazon SES ja Postmark, hyväksyvät kaikki raa'an HTML-sisällön, mikä tarkoittaa, että luotu pohja integroituu suoraan olemassa oleviin sähköpostilähettämisen työnkulkuihin ilman muokkausta. Pohja on sisältöä; lähettämisen infrastruktuuri käsittelee toimittamisen.
Tiimeille, jotka lähettävät sähköposteja säännöllisesti, luontiprosessia voidaan automatisoida. Pohjien kuvaukset, jotka on tallennettu JSON-tiedostoiksi, voidaan lähettää API:lle ohjelmoitavasti, tuottaen päivitettyjä pohjia aina, kun sisältö muuttuu. Tämä automatisointi poistaa suunnittelusta kehittämiseen kuristavan pullonkaulan, joka hidastaa sähköpostin tuotantoa useimmissa organisaatioissa, korvaten sen sisältö-pohja-putkella, joka toimii sekunteissa. Tiimi kirjoittaa sähköpostin sisällön, API käsittelee HTML:n ja ESP käsittelee toimittamisen. Jokainen komponentti tekee, mitä se tekee parhaiten, ja tuloksena on sähköpostin tuotanto sisällön luomisen nopeudella eikä HTML-kehityksen nopeudella.