Archief - Less

Drone · 1 feb 2010

Zijn hier nog andere die al eens met Less gewerkt hebben? Ik ben momenteel bezig met dotless wat er versie is van less voor .net framework.

Less gebruikt gewone css syntax maar het grote voordeel is dat je kan nesten.

Bijvoorbeeld:

Code:

body{
    font-family: Arial;
    background-image: url(../images/bgPage.jpg);
    background-repeat: repeat-x;
}

#Page{
    width: 800px;
    overflow: hidden;
    
    #Content
    {
        width: 600px;
        float: left;
    }
    
    #Sidebar
    {
        width: 200px;
        float: left;
    }
}

Dit wordt dan omgezet naar:

Code:

body {
  font-family: Arial;
  background-image: URL(../images/bgPage.jpg);
  background-repeat: repeat-x;
}
#Page {
  width: 800px;
  overflow: hidden;
}
#Page #Content {
  width: 600px;
  float: left;
}
#Page #Sidebar {
  width: 200px;
  float: left;
}

Je kan ook variables gebruiken en mixins. De dotless versie komt ook nog met de mogelijkheid om je css te verkleinen.

Nu denk je misschien van "Wat voor zever is dat. Ik schrijf mijn css wel gewoon!". Maar als je eens met grote css documenten hebt gewerkt dan weet je direct hoe handig een beetje orde kan zijn. Met Less heb je ook minder code nodig om tot het zelfde resultaat te komen vermits je veel herhaling kan vermijden.

Als je het eens snel wilt proberen ga dan naar hier en download de dotless zip. Daar zit een less.compiler.exe in waar je *.less files kan opslepen die dan worden omgezet naar *.css files. Als je css kent zou de syntax geen probleem moeten zijn.

Curahee Q · 1 feb 2010

Wow nice, soms zie ik inderdaad in mijn css file het bos door de bomen niet meer. Nesting kan inderdaad wel voor veel structuur zorgen. Ga ik zeker eens mee aan de slag.

Zero Grav · 1 feb 2010

't Is wel grappig dat ge als voordeel geeft dat ge minder lijnen kunt verkrijgen terwijl ge zelf (door het weglaten van uw enters) meer lijnen gebruikt voor de 'Less' versie dan.

Nu op zich vind ik het iets minder overzichtelijk. Door alles zo te gaan indenten gaat ge bij grote documenten vaak krijgen dat ge de oorspronkelijke selector niet meer ziet staan op't moment dat ge een bepaald stuk code wilt editten en zo dus ook niet meer weet waar het bijhoort. Door gewoon gebruik te maken van de #page #sidebar notatie hebt ge altijd uw selector op maximum 10 regels boven uw edit staan.

Ik zie ook niet echt in waar de compactheid vandaan zou moeten komen. Uiteindelijk moet ge nog steeds de selector schrijven, alleen laat ge het parent element weg. Maar de lijn van de selector blijft bestaan, die wordt gewoon één of twee elementen korter.

De Mixins zijn wel handig, maar ik kan bij het voorbeeld op Less Css for .NET ook gewoon ".rounded_corners, #header, #footer" schrijven. 't Is gewoon een kwestie van gewenning en voorkeur, maar echt voordelen biedt het niet denk ik.

Bij variabelen vind ik hun voorbeeld slecht om eerlijk te zijn. Ik zou dat gebruiken om bovenaan de pagina mijn kleuren te bepalen voor links, tekst, h*'s, .. zodat ik op een paar minuten het hele kleurenschema van mijn site kan omzetten. Wat zij doen is echt raar en gaat ge in't echt praktisch niet toepassen denk ik.

Maar ge krijgt zeker een reputation puntje voor het leven in de brouwerij en het bieden van een alternatief. En wie weet kan uw antwoord mij toch nog overtuigen.

adrianhates · 1 feb 2010

Curahee Q zei:
Wow nice, soms zie ik inderdaad in mijn css file het bos door de bomen niet meer.

Je kan ook simpelweg uw css opdelen per pagina in verschillende stylesheets en de basis in een basis stylesheet zetten. Dat maakt het alleszins overzichtelijker voor mij

Zero Grav · 1 feb 2010

Maar veroorzaakt wel meer requests, zie hiervoor: Best Practices for Speeding Up Your Web Site
't Is vooral belangrijk om daar een middenweg voor te vinden: Echt één gigantische file is niet goed, maar alles opsplitsen in kleine pagina's qua opmaak nog veel minder.

Curahee Q · 1 feb 2010

Ik hou het liefst bij 1 css file, als het een gigantische file wordt kan ik er wel eens over nadenken.

`SeriOUs · 1 feb 2010

Zero Grav zei:
Maar veroorzaakt wel meer requests, zie hiervoor: Best Practices for Speeding Up Your Web Site
't Is vooral belangrijk om daar een middenweg voor te vinden: Echt één gigantische file is niet goed, maar alles opsplitsen in kleine pagina's qua opmaak nog veel minder.

Maar een gigantische CSS-file qua download moet ik nog wel tegenkomen. Bijna elke afbeelding is stukken groter dan een css-file. Connectie-tijd is vaak de boosdoener.
Maar dan nog, als ge niet voor mobile-content aan het developen zijt, wordt er nog amper naar gekeken.

Leuke info trouwens. Zoiets mag zeker in CSS geimplementeerd worden. Zeker de mogelijkheid tot basis mathematische berekeningen.

adrianhates · 1 feb 2010

Zero Grav zei:
Maar veroorzaakt wel meer requests, zie hiervoor: Best Practices for Speeding Up Your Web Site
't Is vooral belangrijk om daar een middenweg voor te vinden: Echt één gigantische file is niet goed, maar alles opsplitsen in kleine pagina's qua opmaak nog veel minder.

Je kan er met php of .NET

voor zorgen dat je enkel de specifieke stylsheet per pagina oproept , daardoor heb je dus maar 2 css requests / pagina, wat nog vrij normaal is.

Drone · 1 feb 2010

Mijn voorbeeld maakt het inderdaad niet veel compacter in lijnen enkel de parent selectors vallen weg. Het voordeel dat ik ondervond was vooral dat je alles netjes kan groeperen. Ook voor css te onderhouden is dit voor mij veel duidelijker.

Bijvoorbeeld als je dit:

Code:

#Content
{
    background-color: orange;

    #Subcontent
    {
        background-color: blue;
        a
        {
            color: red;
            text-decoration: none;
        }
    }
}

in dit veranderd:

Code:

#Content
{
    background-color: orange;

    a
    {
        color: red;
        text-decoration: none;
    }

    #Subcontent
    {
        background-color: blue;        
    }
}

Je hoeft enkel de <a> stijl van plaats te veranderen. Nu dit is allemaal ook mogelijk in css maar vraagt toch iets meer refactoring.

Voor lijsten vond ik het ook handig.
Voorbeeld van navigatie:

Code:

#Navigatie
{
    overflow: hidden;
    width: 100%;
    
    li
    {
        float: left;
        width: 150px;
        
        a
        {
            text-decoration: none;
            color: green;
        }    
        
        a:hover
        {
            text-decoration: underline;
        }
    }
}

Voorbeeld van nested lijsten:

Code:

ul
{
    li
    {
        font-size: 1.5em;
        
        li
        {
            font-size: 1.25em;
            
            li
            {
                font-size: 1em;
            }
        }
    }
}

Wat ik ook heb gemerkt is dat als imports doet de compiler deze files gaat samenvoegen tot 1 file. Dus dan kan je nog met verschillende files werken en als resultaat 1 minified css overhouden.

Bijvoorbeeld:

Style.less

Code:

@import url(style2.less);

body
{
    font-family: arial;
}

+ style2.less

Code:

body
{
    color: purple;
}

geeft dit :

Code:

body {
  color: purple;
  font-family: arial;
}

Natuurlijk heeft iedereen een manier van werken en dit is maar een alternatief. Ik denk ook als je geen manier hebt om het te automatiseren je best gewoon bij css blijft. Altijd de .less file op de compiler slepen gaat rap irriteren.

Bij .net kan je een httphandler instellen en dan moet je zelfs niks doen. Dan worden alle .less file request direct geparsed. Je kan dan ook minify en cache op true zetten en dan heb je direct ook alle andere voordelen.

Er zijn ook nog andere alternatieven zoals SASS het nadeel hier van is wel dat dit geen css syntrax gebruikt.

Archief - Less

Drone

Legacy Member

Curahee Q

Legacy Member

Zero Grav

Legacy Member

adrianhates

Legacy Member

Zero Grav

Legacy Member

Curahee Q

Legacy Member

`SeriOUs

Legacy Member

adrianhates

Legacy Member

Drone

Legacy Member