There\u2019s more to writing good front-end code than knowing every HTML tag, CSS selector, or the latest front-end features and techniques.<\/p>\n
Using real-world examples found on several websites, let\u2019s take a look at common \u201cred flags\u201d to look for when writing code and evaluating its quality.<\/p>\n
Complex, Overqualified Selectors<\/strong><\/p>\n Look out for complex CSS selectors. For example:<\/p>\n .wrapper .main .post a {…}<\/p>\n These are one of the most \u201cexpensive\u201d selectors in CSS because browsers have to parse a lot of extra elements and selectors. Try to make your selectors as lean as possible:<\/p>\n .post a {…}<\/p>\n Instead of having an overly specific selector,\u00a0it\u2019s usually best to create a class for a particular element:<\/p>\n .continue {…}<\/p>\n Qualifiers in selectors should also be avoided, as they are not reusable, too specific, and create more work for the browser. The nav and p qualifiers in the following selectors are an example of this:<\/p>\n nav.social {<\/p>\n float: left;<\/p>\n }<\/p>\n p.intro {<\/p>\n font-weight: bold;<\/p>\n }<\/p>\n What if at some point you need to use the .social class in a ul or the .intro class in a span? Avoid having to dig through your CSS to fix what you should have done correctly from the get-go, or worse, rewriting the rules unnecessarily.<\/p>\n Relying on Parent Selectors<\/strong><\/p>\n A parent selector lowers the specificity of a child element. Sometimes you can\u2019t avoid them (with anchor elements, for example), but if you have selectors like the following:<\/p>\n .sidebar {<\/p>\n …<\/p>\n }<\/p>\n .sidebar .title {<\/p>\n …<\/p>\n }<\/p>\n a better approach is using a namespace as a modifier.<\/p>\n .sidebar {<\/p>\n …<\/p>\n }<\/p>\n .sidebar-title {<\/p>\n …<\/p>\n }<\/p>\n This keeps sidebar-title self-contained and modular \u2014\u00a0it doesn\u2019t rely on the parent selector and can be used anywhere.<\/p>\n Repeating CSS<\/strong><\/p>\n Avoid repeating the same chunks of code. Look for property\/value pairs that are repeated multiple times throughout the stylesheet, then logically group them so that there\u2019s only one occurrence of that block of code.<\/p>\n .label {<\/p>\n display: inline-block;<\/p>\n }<\/p>\n .button {<\/p>\n display: inline-block;<\/p>\n border-radius: 10px;<\/p>\n }<\/p>\n .field {<\/p>\n display: inline-block;<\/p>\n border-radius: 10px;<\/p>\n padding: 5px;<\/p>\n }<\/p>\n Always think \u201cDRY\u201d(Don\u2019t Repeat Yourself):<\/p>\n .label,<\/p>\n .button,<\/p>\n .field {<\/p>\n display: inline-block;<\/p>\n }<\/p>\n .button,<\/p>\n .field {<\/p>\n border-radius: 10px;<\/p>\n }<\/p>\n .field {<\/p>\n padding: 5px;<\/p>\n }<\/p>\n Resetting and Forcing CSS Values<\/strong><\/p>\n Keep an eye out for rules where you are rewriting CSS properties or setting them back to their initial values. For example:<\/p>\n h2 {<\/p>\n font-size: 1.2em;<\/p>\n font-weight: 700;<\/p>\n padding-bottom: .5em;<\/p>\n border-bottom: 1px solid;<\/p>\n }<\/p>\n h2 styles are then reset further down in another rule:<\/p>\n .post h2 {<\/p>\n font-weight: 500;<\/p>\n padding-bottom: 0;<\/p>\n border-bottom: none;<\/p>\n }<\/p>\n When adding new components, you shouldn\u2019t need to recode or undo patterns and problems you\u2019ve already solved with existing CSS. Instead, a better solution would be to create the following rules:<\/p>\n h2 {<\/p>\n font-size: 1.2em;<\/p>\n }<\/p>\n …<\/p>\n .secondary-headline {<\/p>\n font-weight: 700;<\/p>\n padding-bottom: .5em;<\/p>\n border-bottom: 1px solid;<\/p>\n }<\/p>\n .post-title {<\/p>\n font-weight: 500;<\/p>\n }<\/p>\n Also, !important declarations should never be used to force a CSS value \u2013\u2013 avoid using them unless absolutely necessary.<\/p>\n .last {<\/p>\n border: none !important;<\/p>\n }<\/p>\n !important breaks the natural order of the cascade and, when abused, can lead to maintenance and specificity nightmares. There are few use cases for !important, for example: temporarily testing or debugging CSS issues, overriding certain inline styles when you have no control over the HTML, and aiding accessibility \u2013\u2013 just be careful with it.<\/p>\n Excessive Markup<\/strong><\/p>\n Look for unnecessary use of HTML tags being used for layout:<\/p>\n <p><h4>UX – User Experience Design<\/h4><\/p><\/p>\n There\u2019s no need to wrap the block-level h4 in a p. If you\u2019re using the <p> to give the <h4> extra margins or padding, that needs to be solved in the CSS instead.<\/p>\n IDs Instead of Classes<\/strong><\/p>\n Avoid using an ID wherever you can use a class. IDs are heavy on specificity and cannot be reused. The nav ID shown below can only be used once in a page.<\/p>\n <ul id=”nav”><\/p>\n …<\/p>\n <\/ul><\/p>\n What if you need to add a nav component? Use classes instead:<\/p>\n <ul class=”main-nav\u00a0 nav”><\/p>\n …<\/p>\n <\/ul><\/p>\n …<\/p>\n <ul class=”footer-nav\u00a0 nav”><\/p>\n …<\/p>\n <\/ul><\/p>\n .nav a {<\/p>\n display: block;<\/p>\n color: white;<\/p>\n padding: 5px;<\/p>\n }<\/p>\n .main-nav a {<\/p>\n border-bottom: 1px solid;<\/p>\n font-size: 1.1em;<\/p>\n }<\/p>\n .footer-nav a {<\/p>\n border-bottom: 1px dotted grey<\/p>\n font-size: .85em;<\/p>\n }<\/p>\n It\u2019s best to use IDs as JavaScript hooks or as fragment identifiers in a page. Certainly avoid using one ID for styling, JavaScript, and as a fragment identifier. Doing so will make your architecture fragile because you\u2019re setting up dependencies among CSS, JavaScript, and the fragment identifier.<\/p>\n Closing Thoughts<\/strong><\/p>\n Front-end code that is poorly thought-out can be a strain on maintenance and development in the long run. When writing code, your goal should be making sure that it\u2019s reusable, maintainable, and scalable. Your CSS should also be predictable, so if you need to update or add new components, they shouldn\u2019t affect other parts of your site.<\/p>\n Keep in mind that at some point your site or application will need to scale, which might require more developers working on and maintaining the code. That\u2019s why it\u2019s important to write code that can be easily managed by designers and developers who are looking at our code for the first time.<\/p>\n Are You Looking For Best PSD To HTML<\/a> & PSD To HTML5<\/a> Conversion Service Than Visit Our Website<\/p>\n