skype kontakt - presta.profi

Home » rady tipy » Pixel perfect kodování ano či ne

Pixel perfect kodování ano či ne

Pixel perfect kódování šablon je další téma, které vyžaduje obecné vysvětlení. Pixel perfect je definice pro požadavek přenést z grafického návrhu do kódované šablony maximálně věrnou kopii. Zhotovitel klade především důraz na typ fontu, velikosti a tloušťky fontů, barevnost všech prvků a odsazení.

Ze seznamu výše lze tušit, že pixel perfect kódování je časově náročný proces. Náklady spojené s časovou náročností buď převezme grafik (předá okótované náhledy), nebo kodér (bude nucen si všechny hodnoty zjišťovat).

 Pixel perfect kódování šablony je víceméně o dohodě kdo ponese náklady spojené s přenosem všech detailů a možnostech kodéra.

Nelze automaticky předjímat, že každý kodér si pořídí licenci Photoshopu s využitím pouze na to, aby si zjišťoval detaily fontů a odsazení.
Doba kdy Photoshop byl pro kodéra nezbytný a velká část grafické předlohy se přenášela do šablony, je dávno pryč. Sám jsem si v takovým procesem změny prošel a pro občasné užití bitmapové grafiky Prestashop nepotřebuji.
Moderní kódování je o využití CSS, LESSbootstrap, fontové sady ikon, užití CSV grafiky a dalších technologiích, které optimalizují datovou zátěž, responsivní a multiplatformní užití.

Je pochopitelné, že v době před nástupem mobilních platforem, bylo legitimní, když se tvůrce designu – či klient, obrátil s tímto požadavkem na kodéra a ten po dohodě takovou práci realizoval. Smysluplnost požadavku pixel perfect kódování v dnešní době s užitím mobilních platforem ztrácí smysl.
Každý design se dnes kóduje jako responsive = umožní výrazné změny obsahu ve smyslu kontrolovaného posunu, přesunu, zalomení, změny velikosti, velikosti odsazení a spoustu dalších.

Z dnešního pohledu absolutní změny užití designu a šablony,  jde o velmi nepraktický požadavek, který ve finále uspokojí pouze samotného tvůrce designu a stojí zbytečný čas i prostředky.

 

Designová předloha od grafika prezentuje vždy pouze jedno konkrétní provedení šířky zobrazení, ale šablona se kóduje jako responsive.

 

Seznam neprakticky praktických faktů v neprospěch pixel perfect kódování

  • Grafická předloha prezentuje vždy pouze jednu fixní šířku, obvykle někde kolem 1920px.
    • Už pouze užití prohlížeče s jinou šířkou posuvné lišty může ovlivnit pozici obsahu.
    • Každé další přesně odlišné rozlišení musí nabídnout dynamickou změnu a posun díky provedení responsive.
  • Dektop provedení je tedy nutno chápat jako zobrazení v šířkách 4k monitorů s přesahem do tabletů se zobrazením „na výšku“ minimáně 768px. Následně kódovaná šablona musí umožnit dynamickou změnu zobrazení šířky. To se neobejde bez bez změny pozice a odsazení obsahových prvků. U propracovanějších šablon je pak nezbytná i změnu velikosti fontů pomocí vw velikostí.
  • Tím se dostáváme k technologii užití relativních hodnot při určování velikost fontů a odsazení rem a vw hodnoty nahrazují klasické px hodnoty (více zde).
  • Z logiky věci, všechny velikosti menší než prezentuje grafiká předloha se musí se pohybovat, zalamovat a případně zmenšovat. Pro příklad lišta hlavičky eshopu obsahující: logo, ovladací prvky a horní menu, není možné v menších šířkách, zachovat v původních velikostech a umístění.
  • Ostatní obsah prezentující textové bloky, reklamní upoutávky a produkty, je snaha zachovat. Limitem pro zmenšování, zalomení či změnu pozice je čitelnost a použitelnost.
  • Html i CSS funguje přirozeně tak, že se zmenšováním okna prohlížeče textový obsah ani jeho odsazení nemění. Výjimkou jsou pouze procentuálně definované odsazení a vložené obsahové obrázky s definovaným stylem reponsivního chování.
  • Není možné zajistit a spoléhat, že původní designová předloha si zachová původní provedení a umístění i v menší šířce okna prohlížeče – obsah se procentuálně nezmenšuje.

 

Předem se omlouvám za absurdní příměr níže, ale asi nejlépe vysvětlí absurdní situaci kodéra, který má dnes v užití responsive šablon, požadavek na pixel perfect kódování.

Pixel perfect kódování se dá přirovnat situaci, kdy v restauraci budete požadovat na talíři do detailu totožné jídlo z fotografie na menu.

Pominete chuť a jiný gastronomický zážitek a nad rámec všeho o čem jídlo je = upřednostníte pouze jeho prezentaci. S obecnou znalostí toho jak gastronomická fotografie vzniká = složitý a časově náročný proces, často nevařené jídlo, náhražky, zvlhčování, nasvícení a retuše. Pro nesouhlasící jedince zmíním: ANO existují restaurace, kde Vám na talíři přinesou umělecké dílo, ale právě suroviny, vyhotovení a provedení se více než co jiného zohledňují v ceně produktu.

 

Co vyžaduje Pixel perfect kódování

  • Především sdělit kodérovi že takový postup požadujete.
    • Právě z důvodů uvedených výše nelze předpokládat takovou realizaci automaticky.
    • Pixel perfect kódování v responsive šablonách lze považovat spíše za rozmar, ale pokud je dohoda takovou činnost financovat, je to pouze otázka domluvy.
  • Předat maximálně detailní podklady.
    • Nestačí obyčejný náhled nebo nějaké optimalizované PSD, nezbytností jsou tedy vrstvy, vodící linky, případně slice kostra případně okomentované a okótované náhledy.
    • Je v zájmu zadavatele předat kodérovi jakoukoliv předlohu, kterou bude co nejmenší dobu realizovat.
    • Doba realizace je přímo úměrná ceně vyhotovení, proto časová náročnost s měřením každého prvku designu se musí promítnout do ceny.

Doporučené postupy v pixel perfect realizaci

 

Omlouvám se pokud jsme někomu vzal iluze o tom že pixel perfect je nějaký kvalitativní standard. Požadovat totožnou kopii návrhu je dnes spíše přežitek. S velkou změnou provedení, technologií a mobilními platformami, nedává prakticky žádný smysl. Realizace pixel perfect tak zůstane spíše zbytečně nákladné řešení a v případě aplikace uspokojí pouze tvůrce designu.
Bez znalosti grafické předlohy, nikdo další nedokáže objektivně posoudit, zda grafická předloha byla lepší či horší variantou. Bazírování na na nakódování přesné kopie užitnou hodnotu nijak nezvýší.

Abych vysvětlil v jakém kontextu zde pixel perfect kódování nepodporuji. Kódování responsive designové šablony vyžaduje provedení s užitím reaktivních hodnot velikosti, odsazení a pozice.

 

Pixel perfect kódování v responsive šablonách je záležitost jedné jediné konkrétní šířky okna prohlížeče.

V responsive šablonách běžně aplikuji vizuální shodu = jedná se o kódování, které dodrží ve všech ohledech pohledovou shodu. Je tam zohledněna nezbytnost užití relativních jednotek, chování obsahu při změně šířky okna prohlížeče, multiplatformní a responsivni užití.

I tento způsob kódování samozřejmě vyžaduje pracně zjišťovat hodnoty každého prvku obsahu, následně zapracovat barevnost, fonty, velikosti fontů a tloušťky fontů. Nezbytný rozdíl je také v užití přesných jednotek px, z důvodu moderního technologického užití, jsou nahrazeny relativní jednotkou rem či vw. Nebudu se pouště do vysvětlování, to by bylo na další samostatný článek.
Provedení tedy nesouhlasí pouze v drobných detailech. Pro dosažení vizuální shody absurdně v jednom rozměru by pouze narostl css a html kód designové šablony.

U kódování systémem vizuální shody se fonty liší případně o pixel (kvůli komplikovanému přepočtu px na rem hodnoty), pozice a odsazení je řešeno bez přesných rozměrů pomocí procent nebo rem hodnot s nezbytným zohledněním zalomení obsahu v responsive šabloně.

To jsem ještě nezmínil problematiku odlišných frontových sad v rámci různých operačních systémů (windows, linux, mac), problém s léta nevyřešeným odlišným publikováním html obsahu u různých prohlížečů a odlišným způsobem renderování, užití aliasu a množství dalších drobných odchylek, které se projevují velmi rozmanitě podle každého uživatele.

 

Proto apeluji na zdravý rozum všech zainteresevaných, požadujte vizuální shodu, pixel perfect v multiplatformním užití je spíše utopie.