Share
Ik heb een hekel aan het kijken naar code of mark-up die ik in het verleden heb geschreven, wat ik niet meteen begrijp. Ik ben zeker niet anders dan jij omdat ik jaren later terug wil kunnen komen, de code kan opzoeken en precies begrijp wat er aan de hand is. Ik wil de eenvoudigste concepten niet ontleden, waar de haakjes zich bevinden, of zelfs hoe de mark-up is ingesprongen. Ik heb gewoonten geschapen om me te helpen met een snelle ontwikkeling, die mijn gezond verstand hebben behouden iets intact. Ik zal echter eerlijk zijn, ik heb er nooit over nagedacht hoe ik mijn CSS tot voor kort heb geschreven en georganiseerd, en dat is wat ik vandaag deel..
Er zijn tal van manieren om te doen wat ik suggereer met CSS. Laat mij de eerste zijn om te zeggen, gebruik niets waarover ik vandaag schrijf als uw comfortniveau niet hoog is met mijn concepten. Denk in plaats daarvan na over de concepten en verbeter de oplossingen waarover ik schrijf. Deel uw eigen inzichten. Ik zal niet met je ruzie maken als je denkt dat er een betere manier is om stylesheets te organiseren, omdat er uiteindelijk geen goede of foute manier is. Ik geloof echter dat hoe meer structuur je toevoegt, hoe beter je uiteindelijk bent als je met CSS werkt.
"Hoe gemakkelijk is het voor ons, als ontwikkelaars, om snel een gegeven codebasis te vinden, te begrijpen, te herstellen of aan te vullen? Hoe eenvoudiger die taak is, hoe beter de interne bruikbaarheid."
Er zijn een aantal concepten die ik nu in het algemeen wil bespreken om de hersensappen te laten werken. Ten eerste is er een concentratie op bruikbaarheid met webontwikkeling. We willen dat de gebruikers van onze websites dingen sneller vinden, op een natuurlijkere manier navigeren en in het algemeen intrinsiek de concepten van onze toepassingen begrijpen. Dat is een zeer waardevol gebruik van tijd en energie. Wat soms wordt vergeten, is de interne bruikbaarheid bij alle planning en discussies voor onze projecten. Hoe gemakkelijk is het voor ons als ontwikkelaars om een bepaalde codebase snel te vinden, te begrijpen, te herstellen of aan een gegeven toe te voegen? Hoe eenvoudiger die taak is, hoe beter de interne bruikbaarheid. Naar mijn mening is dat concept onze tijd en gedachte even waardig als de bruikbaarheid aan de voorkant.
Ten tweede, onthoud dat er een C in CSS is. Het is het trapsgewijze deel. De methode die ik gebruik, kan tegen een aantal conventionele gedachten in vliegen, maar wanneer je jezelf in een hoek terugtrekt om alleen bepaalde aspecten van CSS te gebruiken, verlies je de kracht. Wanneer ik een groot project aan het plannen ben, denk ik aan de id selectors als "verklaar de entiteit", class selectors als "beschrijf de entiteit" en stijlattributen als "overschrijven wat ik net heb gezegd". Ik cascade de eigenschappen naar beneden om de code te verminderen, en geef een kleine methode om de waanzin. Nogmaals, er zijn geen goede of slechte manieren, maar als je geen plan hebt, ben je bezig met veel extra werk, om maar te zwijgen over extra overhead.
Tot slot, onthoud dat er altijd compromissen in ontwikkeling zijn. De elegantste manieren om dingen te doen zijn niet altijd het meest efficiënt.
Soms kost de meest efficiënte manier om dingen te doen je de weg wanneer je de code moet terughalen voor ondersteuning.
Niemand kan deze keuzes voor je maken, maar je moet rekening houden met de afwegingen terwijl je schrijft. Soms moet je een klein beetje bijten, misschien om een extra HTTP-verzoek toe te voegen om het eindresultaat intern bruikbaar te maken. Andere keren moet je een goede opmerking toevoegen om jezelf te herinneren aan de keuze die je hebt gemaakt, en verder gaan.
De kans is groot dat u een framework gebruikt om uw CSS te verwerken of dat u uw stijlen toevoegt op een manier die u gewend bent, maar zonder veel structuur. Beide hebben voordelen en nadelen. Laten we eerst een paar CSS-raamwerken bekijken, vanuit de mond van het paard:
Er zijn er nog veel meer, en net als een raamwerk voor uw taalkeuze op de server, hebben ze allemaal hun voordelen ten opzichte van elkaar en hebben ze elk hun nadelen. Ik ben hier niet om je weg te sturen van een raamwerk, zoals ik ze in het verleden heb gebruikt en ik geloof in de concepten. Ik denk dat wanneer je aan een groot team werkt, er geen betere keuze is omdat het je stijlen standaardiseert en het lessen de stem van de individuele ontwikkelaar en ontwerper. Dat gezegd hebbende, denk ik dat er een aantal nadelen aan het gebruik van een CSS-raamwerk kleven, omdat het de overhead verhoogt, met name met stijlen die je niet gebruikt, en de leercurve is behoorlijk hoog. Dit kan een beetje frustrerend zijn, vooral bij projecten met strikte planning. Dat gezegd hebbende, de leercurve is precies dat, een curve, en na verloop van tijd zult u zich meester maken van welk project u ook het beste vindt. Het voordeel van het gebruik van een framework is dat je nu je interne bruikbaarheid hebt verbeterd, omdat je een setmethode-paradigma gebruikt, hoewel die methode hoogstwaarschijnlijk buiten je controle ligt.
De andere oplossing is wat ik het "Wilde Westen" noem, waar alles naartoe gaat. Ik zal eerlijk zijn en zeggen dat ik vaak net iets de deur uit heb geduwd zonder al te veel na te denken over de toekomst, of in het geval van een heel klein project waar de CSS niet erg groot is. De leercurve hier is niet zo slecht, want je schrijft je CSS als je gaat. Je hebt volledige controle over de bestemming van je stijl. Best cool tot nu toe! Het probleem is de interne bruikbaarheid. Kom terug naar dat project nadat het niet langer nieuw in je geest is en er zullen wat problemen zijn. "Waarom heb ik dit in hemelsnaam zo geschreven" of "Ik heb geen idee wat ik met deze opmerking bedoelde" of "Waarom verandert die invoer niet van stijl" of "Wat is dit grote brok chum controlling" zijn veel voorkomende reacties na de stylesheet is niet langer nieuw voor de geest.
Als ik de raamwerkoplossing op een glijdende schaal kon plaatsen met de oplossing in het wilde westen aan de andere kant, denk ik dat ik liever iets in het midden zou hebben. Hoewel een bed te hard is en het andere bed te zacht is, wil ik het bed vinden dat precies goed is. Dat is wat ik de hybride oplossing noem. Het deelt kenmerken met zowel het wilde westen als kaders. Aan de ene kant heb ik controle over mijn stijlen, en daarmee is de leercurve nogal laag. Anderzijds wil ik een beetje structuur geven aan wat ik schrijf, zodat wanneer ik er later op terugkom, ik op zijn minst een vertrouwdheid van de structuur heb omdat ik verder bouw op mijn methoden die elk project.
Het is een beetje een doe-het-zelf-project zoals in huisverbetering. U ruilt de structuur en kosten van een professional in voor het gemak en de vertrouwdheid van het gebruik van uw eigen handen om het werk te doen. Waar je uiteindelijk op hoopt, is hetzelfde afgewerkte project, maar dan zonder de leercurve of buitenlandse ideeën en concepten uit de industriële krachtversie.
Terugdenkend aan de keuzes die we als ontwikkelaars moeten maken, maak ik de keuze om de HTTP-verzoeken voor een iets betere organisatie te verhogen. Ik weet dat ik mezelf wat prestaties kost, maar uiteindelijk krijg ik CSS die makkelijker te begrijpen is als ik ze daarna moet bekijken. Je kunt hier een andere keuze maken en je zult niet veel ruzie van me krijgen. Ik geef de voorkeur aan kleinere bestandsgroottes die op een consistente manier zijn geordend over het ene grote CSS-bestand of kop in mijn HTML.
reset.css : Een reset-css is er een die ervoor zorgt dat alle of ten minste een groot deel van de browserstijlen teniet wordt gedaan. Ik gebruik een reset-css zodat ik enkele verschillen met browsers kan bestrijden en ik zie de waarde als het gaat om problemen met verschillende browsers. Het is geen Nirvana en sommige geven er de voorkeur aan om geen reset uit te voeren, of wat ik onlangs heb gelezen, een zachte reset. Ik geef de voorkeur om alles opnieuw in te stellen en ik gebruik de Eric Meyer-smaak van resets.
forms.css: Ik scheid mijn formulierstijlen van de rest van mijn CSS. Ik wil weten wanneer ik aan formulieren werk, en ze verschijnen niet helemaal zoals ik precies wil.
global.css: Mijn globale css-bestand is iets dat ik gebruik voor elk groter project dat ik schrijf. Wat in dit kleine bestand zit, zijn kleine klassen die ik steeds weer in projecten zou kunnen gebruiken. Mijn vuistregel is dat als er een snelkoppeling voor de eigenschap is, deze waarschijnlijk niet in het globale bestand thuishoort. Ik zou de eigenschap font niet gebruiken. Bijvoorbeeld:
/ * Kleuren * / .red color: red; achtergrond: erven; .blauw kleur: blauw; achtergrond: erven; .licht kleur: zwart; achtergrond: geel; / * Lijsten * / .horizontal list-style-type: none; weergave: inline; .vertical list-style-type: none; weergave: blok; / * Tekst * / .small font-size: small; .large font-size: large; .bold font-weight: bold;
Merk op dat dit zeer specifieke klassen zijn, die bijdragen aan de trapsgewijze regels van stijlen. Hoewel er in het algemeen niets wordt gebruikt als de enige stijl voor een element, voegen ze toe aan de beschrijving van het element waarop deze klasse wordt toegepast.
style.css: Mijn style.css is mijn belangrijkste controller van mijn stijl. Als je denkt in termen van OO voor CSS, is mijn style.css mijn klas, terwijl de andere bestanden mijn klasse uitbreiden (enigszins sowieso) en toevoegen aan de overerving van mijn hoofdobjecten. Ik gebruik mijn style.css om mijn andere bestanden te importeren en om mijn lokale, alleen project, id selectoren en klassen te definiëren.
Mijn hybride methode wijkt hier af van de meeste mensen, omdat mijn algemene regel met id's alleen maar is om het element in kwestie uit te leggen. ID Selectors worden maar één keer per pagina gebruikt (inclusief GET-processen), dus ik wil dat deze zeer specifiek van aard zijn. Om het hergebruik van code echt te maximaliseren, elke eigenschap buiten die uitleg van een element, zou ik echt de voorkeur geven aan een klassenkiezer. Omdat deze ID uniek is voor de pagina, wil ik alleen maar unieke uitleg gebruiken voor deze selector.
Mijn breedte zou bijvoorbeeld enigszins uniek zijn. Mijn opvulling en marge zou enigszins uniek zijn. Mijn positie zou enigszins uniek zijn. Je zou kunnen betogen dat het scherm voor deze selector enigszins uniek zou zijn. Mijn kleur voor het element; niet echt uniek. Mijn achtergrond, opnieuw niet echt uniek. Voor de niet echt unieke items, denk ik aan deze als "beschrijf het element" waarvoor ik class selectors gebruik.
Laten we dit illustreren met een kleine code. Voor het gemak gebruik ik een recente tutorial van Jeffrey Way getiteld Quick Tip: Practical CSS Shapes. Wat als we de originele CSS hebben gebruikt:
#container background: # 666; marge: automatisch; breedte: 500 px; hoogte: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif; h1 background: # e3e3e3; achtergrond: -moz-linear-gradient (bovenaan, # e3e3e3, # c8c8c8); achtergrond: -webkit-gradiënt (lineair, links bovenaan, links onderaan, vanaf (# e3e3e3), naar (# c8c8c8)); opvulling: 10px 20px; marge links: -20px; margin-top: 0; positie: relatief; breedte: 70%; -moz-doos-schaduw: 1px 1px 3px # 292929; -webkit-doos-schaduw: 1px 1px 3px # 292929; vakschaduw: 1px 1px 3px # 292929; kleur: # 454545; tekstschaduw: 0 1px 0 wit;
en getransformeerd naar dit:
#container margin: auto; breedte: 500 px; hoogte: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif; # heading-one opvulling: 10px 20px; marge links: -20px; margin-top: 0; positie: relatief; breedte: 70%; .norm-achtergrond color: #fff; achtergrond: # 666; .heading-fancy background: # e3e3e3; achtergrond: -moz-linear-gradient (bovenaan, # e3e3e3, # c8c8c8); achtergrond: -webkit-gradiënt (lineair, links bovenaan, links onderaan, vanaf (# e3e3e3), naar (# c8c8c8)); -moz-doos-schaduw: 1px 1px 3px # 292929; -webkit-doos-schaduw: 1px 1px 3px # 292929; kleur: # 454545; tekstschaduw: 0 1px 0 wit;
Tot dusverre heb ik alleen echt twee nieuwe klassen uit de unieke h1-selector toegevoegd en die h1 uitgetekend tot een unieke ID. Ik heb op dit moment niets gewonnen, en in werkelijkheid heb ik nog een beetje meer overhead aan mijn bestand toegevoegd. Waar is het voordeel dan?
Als je even denkt dat je deze beschrijvingen ergens anders zou kunnen hergebruiken, misschien voor een subtitel, dan hebben we wat hergebruik van code. Laten we kijken om te zien wat we nu kunnen doen. Hier ziet u hoe het er oorspronkelijk uitziet:
en zo ziet het eruit met een subtitel:
Ik heb nu alleen een nieuwe definitie toegevoegd:
# heading-two opvulling: 10px 20px; marge links: -20px; margin-top: 0; positie: relatief; breedte: 30%;
Samen met een beetje HTML:
Mijn richting
Mijn subrubriek
We hebben code opnieuw gebruikt en we hebben een methode die consistent is. Als u deze methode gebruikt en toepast, vermindert u het aantal stijlen (of objecten als u dat liever hebt) dat u schrijft. Minder code met een methode betekent eenvoudiger ondersteuning op een later tijdstip. Werkelijk niets aan de hand, maar als je je ID-selectors begint te verklaren maar je klassen beschrijft, is het een eenvoudige methode om een beetje gezond verstand aan je code toe te voegen.
Ik ben er zeker van dat iemand je ooit heeft verteld om nooit het stijlattribuut te gebruiken. Ik ben er ook zeker van dat sommigen van u het niet met me eens zullen zijn, en dat is OK, ik kan het aan. Ik ga die regel een beetje onderbreken met een voorbehoud. Gebruik het nooit zonder een beetje na te denken over wat je doet. Er zijn legitieme toepassingen voor het stijlkenmerk, met name bij het werken met complexe toepassingen met AJAX-aanroepen, maar die gebruiken komen uit uw gedragslaag.
Wanneer u het stijlkenmerk moet gebruiken, moet u een snelle laatste oproep plaatsen om iets in de cascadeweergave op te heffen voor het element dat niet zinvol is om toe te voegen aan uw bestand global.css. U moet bijvoorbeeld mogelijk een stijl uit uw gedragslaag overschrijven op basis van een gebruikersactie. Het voegt een beetje toe aan de complexiteit, maar het draagt bij aan de cascade. Ik zou niet meerdere eigenschappen gebruiken, omdat dit een snelle override is, of beter gezegd: "vergeet wat ik je net heb verteld, doe dit in plaats daarvan". Het is een cascade en je zou je CSS als zodanig moeten behandelen, naar mijn mening.
We besteden veel tijd aan het benadrukken van onze inspringing in onze code en HTML, maar ik zie niet vaak dezelfde nadruk in onze CSS. Het maakt de wereld van verschil. Laten we ons voorbeeld opnieuw nemen:
Mijn richting
Mijn subrubriek
Als we dat aangeven in onze opmaak, waarom dan niet op dezelfde manier inspringen in onze CSS:
#container margin: auto; breedte: 500 px; hoogte: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif; # heading-one opvulling: 10px 20px; marge links: -20px; margin-top: 0; positie: relatief; breedte: 70%; # heading-two opvulling: 10px 20px; marge links: -20px; margin-top: 0; positie: relatief; breedte: 30%;
Het voegt net iets meer nadruk toe op wat er met deze ID-selectors aan de hand is. Ik begrijp nu dat ze kinderen zijn van de container div zonder mijn prijs te vergelijken.
Bij het kiezen van de lay-out van uw stijlbestand is dit de vuistregel die ik gebruik. U moet uw extra CSS-bestanden @importeren eerst met het bestand reset.css en vervolgens de rest. Definieer uw elementen zoals h1, ankers, enz. Definieer vervolgens uw ID selectors in uw style.css. Als u met meerdere pagina's werkt, becommentarieer dan het begin van elke nieuwe pagina binnen uw inspringing. #Container is bijvoorbeeld waarschijnlijk een element van de lay-out dat de container voor elke pagina is, dus begin daar met uw inspringing en werk commentaar uit waar u elk element gebruikt. Definieer tenslotte uw klassen. Ik teken normaal gesproken niet mijn klassen, vanwege het feit dat ze vaak worden hergebruikt en de inspringing niet aangeeft waar ze worden gebruikt.
Tenslotte, en waarschijnlijk het allerbelangrijkste, geef commentaar op uw CSS op dezelfde manier als de code op uw server. Als er een context is die u aan een klasse kunt geven, zoals elementen die worden gebruikt, of een ID die overeenkomt, noteer deze dan. Elke context die je je toekomstige zelf geeft is als het hebben van een tijdmachine. Marty McFly heeft misschien die griezelige vent niet uit de buurt van tegenliggers geslagen als hij net de Flux-condensatorcommentaar had gelezen.
Ik ben er vrij zeker van dat mijn methoden geen nieuwe dansbeweging er naar vernoemd zullen hebben, en zal ook geen kanker genezen. Ik weet niet eens zeker of ze door een persoon buiten mijn naaste familie zouden worden aangepast. Dat gezegd hebbende, hoop ik echt dat je de concepten hiervan weghaalt en methoden gaat bouwen die voor jou werken. Ontwikkeling bruikbaarheid is een doel dat we allemaal moeten nastreven. Wanneer u een methodologie maakt, verhoogt u uw interne bruikbaarheid exponentieel omdat u gewoonten ontwikkelt die u opnieuw gebruikt en deelt met uw team en anderen. Het lost ontwikkelingsproblemen op, verhoogt de productiviteit en verlaagt de algehele ontwikkelingskosten. Het is een van die zeldzame win / win-proposities die je tegenkomt in je dagelijkse ontwikkelingsleven.
Bedankt voor het lezen en deel uw ideeën.
Accentsconagua