Autor Zpráva
radekt
Profil
Dobrý den,
V současné době LESS vytvářím v PSPadu a CSS kompiluji programem WinLess. LESS, v kombinaci s LESS Hat, se mi osvědčil jako vynikající nástroj. Kód kopíruje strukturu DOM, to znamená lepší orientaci v něm, je stručnější než CSS; LESS Hat za mě řeší vendor prefixy. Mám dotaz jak optimálně organizovat LESS kód a pak jsem narazil na ne úplně optimální výstup CSS (vedle WinLessu jsem zkoušel i Koalu).


Mám-li kód LESS:
html { 
  background: #EDEEF2;
  body {
    width: 90%;
    #main { 
      background: white;
    } 
  }
}

Je vygenerován výsledný kód (pro lepší orientaci bez minifikace):
html {
  background: #EDEEF2;
}

html body {
  width: 90%;
}

html body #main {
  background: white;
}

Výsledný kód jde ovšem proti požadavku rychlého načítání dat na mobilních zařízeních, tedy co nejstručnějšího CSS. "Postaru" bych udělal stručnější kód (html, body a identifikárory se v kódu html nevyskytují duplicitně):

html {
  background: #EDEEF2;
}

body {
  width: 90%;
}

#main {
  background: white;
}

Existuje program, který by to uměl zkompilovat lépe?

Tendence soustředit se na mikrobreakpointy místo na globální breakpoint vede kódera od používání složených deklarací, výsledkem je zase "upovídanější" CSS.

Co se týče organizace LESS kódu a řešení těchto úskalí, jsem se dopracoval k takovémuto způsobu:

// knihovna LESS mixinů LESS Hat
@import "lesshat.less";

// vlastní mixiny
.flexbox_vertical () {
.display(flex);
.flex-direction(column);
}

.flexbox_horizontal () {
.display(flex);
.flex-direction(row);
}

// složené deklarace
h1, h2, h3 {color: green}

// html, body
html {
  background: #EDEEF2;
}

body {
  width: 90%;
}

// pak teprve kód kopírující DOM strukturu
#main {
  background: white;
  ul { font-weight: bold; }
...
} 

// styl pro zařízení s větším displejem
@media all and (min-width: 600px) {
...
}

// nakonec styl pro MSIE 9 a nižší (html class) */
.ie9 {
...
}

Je toto optimální? Jak to řešíte vy?

Děkuji
Radek Tůma
Keeehi
Profil
Ten druhý a třetí jsou jiné kódy. Chápu že v 99.99% případů budou v prohlížeči fungovat stejně, ale taky se dá napsat html kód tak, aby stejně nefungovali. Takže to co bys chtěl ti nemůže splnit žádný správně napsaný kompilátor. Ani less ani žádný jiný.
radekt
Profil
Děkuji. Takže i způsob, kterým se snažím dosáhnout menšího CSS bude plus mínus optimální.
Chamurappi
Profil
Potíž je, že priorita selektoru je dána tím, z čeho je složený. Což byla prapůvodně chytrá finta, ale občas to může být docela otravné nebo zbytečně neefektivní. Kodéři píší mnohdy zbytečně podrobné selektory na základě nějaké intuice, kudy se bude/může dané HTML dál vyvíjet, nebo v případě kolize dodatečně zvedají priority tomu, co má vyhrát (podobně, jako když rostou z-indexy věcem, které mají být vždy navrchu, než se najde něco, co má být ještě víc navrchu).

Společně se znalostí chování CSS vlastností jsou dle mého názoru tato intuice a schopnost dodatečného záplatování základním měřítkem kvality kodéra – je to i důvod, proč bývá déle kódující člověk lepší, než začátečník, který se poctivě nabifloval všechny vlastnosti a tabulky kompatibility. Všelijaké CSS frameworky zkouší tuto hloubku kodérského řemesla obejít víceméně hrubou silou (pokrýt všechny obvyklé situace), případně ji nahradit novou sebekázní a poučkami, co se má jak dělat, ale myslím, že málokdo přemýšlí nad tím, jak ji úplně zrušit… což ovšem neznamená, že to nejde.

Šlo by mít preprocesor, který by zpracovával i deklarativně zapsanou HTML šablonu, a jím sestavené CSS by bylo stoprocentně ušité na míru všem popsaným variacím HTML. Žádné zbytečné selektory, žádné duplicitní zápisy, žádné smetí, žádné zbytečně silné kombinace, jen jeden malý extrémně efektivní balíček. Kodér by stále nějak musel vyjádřit, co vlastně chce, ale tu těžší část by za něj zmáknul počítač.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0