Knowledges in Computer Science

Choose your interests from a vast range of topics

notes

notes

Cyber Law

Cyber Laws

Implementing perceived wisdom

Implementing perceived wisdom At the time, the principle approaches for dealing with CSS at scale were: OOCSS (Object Orientated CSS), developed by Nicole Sullivan SMACSS (Scalable and Modular Architecture for CSS), developed by Jonathan Snook BEM (Block Element Modifier), developed by Yandex Now, I'll tell you unashamedly right now, I've stolen elements from each. However, none of those actually solved the problems I had. Before we get to ECSS proper I'd like to briefly go over the advantages and disadvantages of each of the existing approaches I looked at. That way, at least when we get to ECSS you can appreciate the problems it is solving. On OOCSS The most widely practised, and certainly most widely lauded of the existing approaches I looked at was OOCSS. That was the first approach that I utilised when trying to wrestle my ever growing CSS codebase. One of the principal arguments for an OOCSS approach is that it removes duplication of code and therefore results in a more maintainable CSS codebase. In essence, you build a set of CSS 'Lego' pieces you can then use in your HTML/templates to quickly build out designs. The hope is that once your OOCSS styles are written they shouldn't grow (much). You re-use where possible and extend where needed. Before we look at OOCSS I need to get some caveats out there. This isn't an attack on OOCSS, Atomic CSS or any related single responsibility principle (SRP) approaches. It's merely my argument that a different approach, depending upon your goals can offer a preferential outcome. I'm not suggesting that the approach I advocate is a panacea to all CSS scaling problems. It is not (there are none). Responsive web design, the Achilles heel of OOCSS For me, the two biggest problems with an OOCSS approach are: Responsive Web Design Frequent design changes and on-going maintenance Let's see if I can demonstrate why I feel these two issues are worth considering. Responsive issues I consider Atomic CSS (not to be confused with Atomic Design) to represent OOCSS taken the the nth-degree. Let's consider an imaginary Atomic CSS example: <div class="blk m-10 fr">Here I am</div> In this OOCSS/Atomic CSS example, the visual needs of the element have been split up/abstracted into re-usable classes. One sets a block formatting context (.blk), another sets some margin (.m-10) and finally one provides a floating mechanism for the element (.fr). Un-opinionated and terse for sure. In principle, Atomic CSS is very similar to the first architectural approach I devised. It was called 'PST!' which was an acronym for Position Structure Theme. The idea was this: there would be no semantic HTML classes/CSS selectors. Instead, every element on the page could be described by its position, structure and theme. Each new selector would just take the next available number. For example, s1, s2, s3 and on and on. It wasn't quite a class for each responsibility as is the case with Atomic CSS but it was a way of heavily abstracting stylistic needs. Markup looked like this: <div class="p1 s3 t4">Content</div> Like Atomic CSS it was terse, and there was no pondering on what to call something as you authored but in practice it was hugely problematic, for the same reasons described in this section. However, what happens when the viewport changes and we don't want 10px margin or the item floating? We could of course make some classes to do things at certain breakpoints. For example, Mplus-cc2 might change a colour at an 'Mplus' breakpoint (Mplus here would be 'Medium' size viewports and above). But I found this practice to be slow and laborious. Making very specific changes at certain breakpoints and tying them to a class that has to be added to the HTML seems needlessly complex. Furthermore, you inevitably end up with a raft of SRP classes in your style sheets that are obsolete. What's the authoring mechanism for removing any cruft from the authoring styles sheets when no longer needed? Maintenance and iteration Let's continue with our prior example. Suppose at some point in the future, we change our product to a more progressive layout mechanism; we move from float based layouts to Flexbox based layouts. At this point, we will now have twice the maintenance burden. We will need to not only change classes in the markup/templates but also alter the CSS rules themselves (or write entirely new ones). Furthermore, using float is redundant with Flexbox so either we leave .fr alone (and so it continues to exist, needlessly in our CSS) or we make .fr responsible for something else such as justify-content: flex-end. But then what happens if we change the flex-direction of our parent at a particular viewport? Arrgggghhhh! Hopefully you can see the inherent shortcomings of an OOCSS approach for maintenance when your designs change frequently or you need to render an entirely different layout at a different viewport? Atomic CSS has developed considerably since Thierry's article in Smashing Magazine back in 2013. Depending upon your goals, it may be just the thing you need, I'd encourage you to check the project out at http://acss.io. A pure OOCSS example It would be fair to argue that using Atomic CSS as an example is unfair, and perhaps doesn't fairly represent OOCSS. However, trying to get a canonical example of OOCSS is difficult as there seems to be so much disparity between what CSS authors believe it is, and how it is implemented. I'll therefore provide some further, OOCSS only, examples. I'm going to use Nicole Sullivan's original examples from her slides 'Our best practices are killing us'. I was reluctant to do this as Nicole's original examples are now very old (2009, before Responsive Web Design was even a thing) and, without wishing to speak for her, I dare say she might use a different example and approach today. However, hopefully we can agree that the essential aims of OOCSS are separation of structure from skin, and separating content from container? Assuming we are in agreement on that, it is my conviction that OOCSS is detrimental to speed of creation and codebase maintainability in certain circumstances. In a responsive web design, there are times where the structure is the skin. Or rather, the structure does different things in different contexts, and there is no sane way to handle this with OOCSS. You however will be the judge. Consider this OOCSS example. First the markup: <div class="media attribution"> <a href="#" class="img"> <img src="mini.jpg" alt="Stubbornella" /> </a> <div class="bd">@Stubbornella 14 minutes ago</div> </div> Now the CSS (note, I have removed some OldIE specific property/values here): .media { overflow: hidden; margin: 10px; } .media .img { float: left; margin-right: 10px; } .media .img img { display: block; } .media .imgExt { float: right; margin-left: 10px; } However, maybe this media object needs to be laid out differently at a 300px wide viewport. You could set a media query to make it a column based layout in that situation. But let's say you have the same 'object' in a different context at the same viewport width? And in that context, it shouldn't be in a column layout. To surmise: One media object needs to be a column based layout at 300px wide (let's call this 'media1') A second media object needs to be a row based layout at 300px wide (as it is within another context/container, we will call this 'media2') Let's make a class that separates more concerns. It makes a media object a column layout at a certain viewport: @media (min-width: 18.75rem) { .media-vp-small { /* Styles */ } } That gets added to any element that needs to be a column at that viewport ('media1') so you'll need to head over to the templates/HTML to make that change, adding the class where needed. Furthermore, 'media2' needs to have a different background colour at a larger viewport. Let's add another class to separate that concern: @media (min-width: 60rem) { .draw-focus { /* Styles */ } } Head into the HTML/template to add that style where needed. Oh, and 'media1' needs the .img to be wider at the larger viewport and not have the margin. We can make another class for that: @media (min-width: 60rem) { .expand-img { width: 40%; margin-right: 0!important; } } Back into the HTML/templates to make that change happen. Hopefully now, you can see where this is headed? There's a lot of Single Responsibility Principle (SRP) classes being added to facilitate the many and varied scenarios our media object needs to facilitate. This approach was not making my large responsive code base more maintainable. In fact, quite the opposite. Whenever changes were needed it was necessary to go hunting for the particular SRP class for the specific situation and often add/remove HTML classes in the markup/templates too. Which made me ponder the question: Why can't the thing, just be the thing? For now, you may counter with, 'this is a daft example, if a design has so many eventualities, it should be normalised'. At which point I would counter that it shouldn't be necessary to. Those tasked with coding the front-end shouldn't need to hobble a designers creativity just because it makes their code less predictable. They should be able to code out a new design simply and easily without concerning themselves about how the new component/module/thing may impact others. Trying to prevent visual changes to a project merely because they make our codebase difficult to maintain is not a defensible stance. We should be able to build out any new visual treatment with speed and predictability without fear of inadvertently affecting other areas of the project. When I've used OOCSS to tackle my needs, my speed to build new visuals decreased and the amount of single responsibility principle classes increased; often a class is used just once or twice on an entire project. When using OOCSS on a rapidly changing project I also found that after some time, I found it incredibly frustrating to 'unpick' these abstract classes when changes were needed. I was having to make many very similar abstract classes when they were seldom actually used. Utility classes like w10, w15, w20, w25 etc for different width percentages seemed like a good idea and an obvious abstraction to make but they ultimately proved useless and problematic to iterate designs with (back to the problem of things needing to do different things in different contexts). My first big lesson when employing OOCSS therefore was the same lesson that the fine fellow Kaelig Deloumeau-Prigent learnt in his time working on large CSS codebases at the BBC and The Guardian newspaper: Two years ago I wrote a book where I was preaching DRY code, but after working on enduring projects, it's "decoupling" that became more important to me. On large, rapidly changing projects, being able to easily decouple visual modules from the project is incredibly important for ongoing maintenance and OOCSS didn't facilitate this need well. SMACSS SMACSS, which stands for Scalable Modular Architecture for CSS, is detailed fully in Jonathan Snook's book on the subject. I'm not going into detail about SMACSS here as I think you should go and check that book out for yourself. Reading SMACSS gave me plenty to chew over as I faced my own challenges and I certainly took things, such as how to think about state changes, from it. However, I will detail why SMACSS didn't work for me. Again, like my caveat regarding my opinions on OOCSS, this isn't a critique of SMACSS. It's simply highlighting the parts that didn't work for me and why I felt it failed to solve my own problems. SMACSS has clearly defined terminology and concepts for the visual aspects of a website. It therefore prescribes base, layout, modules and optional theme rules/files to support these definitions. For example, consider this suggested file structure: +-layout/ | +-grid.scss | +-alternate.scss +-module/ | +-callout.scss | +-bookmarks.scss | +-btn.scss | +-btn-compose.scss +-base.scss +-states.scss +-site-settings.scss +-mixins.scss” Excerpt From: Jonathan Snook. “Scalable and Modular Architecture for CSS.” While these definitions make perfect sense in many scenarios, they didn't for mine. I wanted an approach that was looser, an approach that didn't make me need to consider fitting what I needed to build into those visual definitions; the applications I was building and maintaining often defied adherence to those definitions. BEM BEM is a methodology developed by the developers at http://yandex.ru. The key thing I took from BEM (which stands for Block Element Modifier) is just how much a naming convention can buy you when it comes to CSS maintenance. If you are interested in reading more about BEM, the canonical resource is http://en.bem.info. For a good explanation of where it all began I recommend starting here: https://en.bem.info/method/history Again, like SMACSS I'm not going to attempt to fully explain the ins and outs of BEM methodology. However, I will give you the 'elevator pitch' explanation of the key points. The BEM methodology works around the notion that key areas of a page can be defined as 'Blocks'. In turn, those key areas are made up of Elements. We can then represent the relationship between the Block and its Elements in the way we name things. Consider the OOCSS media object example from before. In a BEM approach we might use classes like this: <div class="media"> <a href="#" class="media__img"> <img class="media__headshot" src="mini.jpg" alt="Stubbornella" /> </a> <div class="media__attribution">@Stubbornella 14 minutes ago</div> </div> What's so useful about this naming scheme is that it clearly communicates a relationship between the elements and the block they belong to. Plus, away from the HTML, if we came across a selector like this in the CSS: .media__headshot { } We instantly know that this is a Element called 'headshot' that lives inside a Block called 'media'. This namespacing a component as part of something else helps to isolate styles and prevent the applied styles from 'leaking' out – one of my major bug-bears with OOCSS. This was definitely a step in the right direction for the problems I was trying to solve. BEM also has the notion of 'modifiers'. A modifier is something that gets added to the Block to modify its appearance. Suppose we wanted to theme our media object differently in a different scenario. BEM facilitates it like this: <div class="media media_dark"> <a href="#" class="media__img"> <img class="media__headshot" src="mini.jpg" alt="Stubbornella" /> </a> <div class="media__attribution">@Stubbornella 14 minutes ago</div> </div> The BEM documents dictate the use of a single underscore character to identify a Modifier for a Block. This modifier class must always be used alongside the block name. For example, you must do this: <div class="media media_dark"> And not this: <div class="media_dark"> I see the value in using modifiers in this manner but it proved problematic for me. Often the things I was styling needed to behave differently in a more traditional manner. Perhaps visuals needed to display differently depending upon the context they were being used, or if another class was being added above it in the DOM. Or due to certain media query conditions, or indeed any combination of those scenarios. I needed a way to author styles that was pragmatic enough to deal with the non-ideal situations that occurred. Some way to keep some sanity in the authoring style sheets no matter what was thrown at them.

Introducing ECSS

Introducing ECSS I'm not about to try and convince you that the Enduring CSS approach is the 'Alpha and the Omega'. However, it does have different strengths and aims than the existing approaches. Therefore, even if taking it wholesale doesn't appeal, I'd hope there may be something you can borrow to solve your own issues. Highlights of ECSS: It gains maintainability by isolating each visual pattern. File size remains minimal over long periods of time by virtue of the fact that you can cut out sections/features/components with impunity. Rules are 'self-quarantining'. Class names/selectors can communicate context, originating logic and variation. All language/technology files that create a module are contained within a shared folder. When I first wrote about Enduring CSS I was expecting a backlash of sorts. At that time (August 2014), no-one was really advocating what I was suggesting. Common perceived wisdom was to abstract visual patterns, normalise designs as much as possible and DRY out code. Enduring CSS is in some ways the antithesis of these beliefs. In case you aren't aware of the acronym, DRY stands for Don't Repeat Yourself, a popular goal when coding so that logic is only written once in a codebase to provide a single source of truth. Before we get into this, I think it may help to clarify the terminology that will be used. The terms used to define the visual parts of a page are known by different names in different approaches. There's nothing revelatory in what I'm suggesting or the terms I'm using, it's just important we're all on the same page before we get into this. Defining terminology I'm using the term 'module' to designate an area of functionality and/or the code that creates it. To exemplify, the header of a website could be considered a module. The header module would, in turn, be made up of other smaller pieces of functionality. For example, drop-down menus or search boxes. These nested pieces of functionality would be defined as components. Finally, our smallest 'items' would be the child nodes that make up a component or module. So, to reiterate: a module is the widest, visually identifiable, individual section of functionality. components are the nested pieces of functionality that are included within a module child nodes are the individual parts that go to make up a component (typically nodes in the DOM) For brevity, for what follows, when I'm referring to modules, it could be a module or component. The difference from a ECSS authoring perspective is unimportant. The problems ECSS solves My primary goal with ECSS was to isolate styles as opposed to abstracting them. Ordinarily, it makes sense to create CSS classes that are abstractions of common functionality. The benefit being that they can then be re-used and re-applied on many varied elements. That's sound enough in principle. The problem is, on larger and more complicated user interfaces, it becomes impossible to make even minor tweaks and amendments to those abstractions without inadvertently effecting things you didn't intend to. A guiding principle with ECSS therefore was to isolate styles to the intended target. Depending upon your goals, even at the cost of repetition, isolation can buy you greater advantages; allowing for predictable styling and simple decoupling of styles. A further advantage of isolating styles is that designers can be encouraged to bring whatever they needed making, without needing them to be encumbered by existing visual patterns. Every new module that needs to be coded can be a 'greenfield'. I found that I could code out designs far faster when starting from scratch than attempting to build them from any number of vague abstractions. Dealing with specificity I also wanted to negate issues surrounding specificity. To this ends, I adopted the widely used approach of insisting all selectors used a single (or as close to that ideal as possible) class-based selector. If you're having CSS problems I feel bad for you son, I got 99 problems but specificity ain't one. https://twitter.com/benfrain/status/537339394706141184 Furthermore, structural HTML elements (with the exception of pseudo-elements) are NEVER referenced in the style sheets as type selectors. In addition ID selectors are completely avoided in ECSS. Not because ID selectors are bad per se, but because we need a level playing field of selector strength. 'Changes' to components are handled via simple overrides. However, the way they are handled from an authoring perspective makes them easy to manage and reason about. Suppose you have an element that needs to be a different width if it is within a certain container - easy peasy, we don't need to be draconian in the manner an override can happen. We don't need a modifier applied to that specific element. We can handle very loose and typical scenarios but manage them confidently. You would write it like this in the authoring style sheets: .my-Module_Component { width: 100%; /* If in the sidebar */ .sw-Sidebar & { width: 50%; } } And it would yields this CSS: .my-Module_Component { width: 100%; } .sw-Sidebar .my-Module_Component { width: 50%; } This may seem like a subtle benefit. After all, we may be authoring things a little differently, by nesting the overrides, but the net result is typical CSS; an element that gets different styles based upon a different and more specific selector. However, by adopting this approach, from an authoring perspective, we create a 'single source of truth' for each key selector. Everything that will ever make a change to that key selector is nested inside that set of curly braces. Furthermore, that key selector will never be defined as a root rule again. This approach is a subject we will touch on later in the book. Different interpretations of DRY I wasn't convinced that the goal of DRY code that other CSSers were pursuing and extolling the virtues of, was the same kind of DRY code I wanted. To explain that a little more - I didn't care much about repeated values and pairs across my rules, which is what most people were concentrating on DRYing out. What I cared about was key selectors not being repeated in the codebase. Key selectors were my 'single source of truth' and that was the area I wanted to DRY out. To that ends, with ECSS, an authoring convention is enforced that prevents a key selector being defined more than once project-wide. We will get into that in much more detail in the 'Ten Commandments of Sane Style Sheets' chapter. This is !important If on the odd occasion the presence of one one override isn't enough, we can rely on !important. Although !important has little to do with specificity, you will likely be aware that in the wrong situation it should be avoided. Here's what MDN has to say about !important: When an !important rule is used on a style declaration, this declaration overrides any other declaration made in the CSS, wherever it is in the declaration list. Although, !important has nothing to do with specificity, using !important is bad practice because it makes debugging hard since you break the natural cascading in your stylesheets. https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity However, when events beyond our control mess with our styles (e.g. a 3rd party CSS file loaded on the page) and we need some clout, we can embrace !important. Here's an example of a state change that is receiving some extra welly from !important: [aria-expanded="true"] & { transform: translate3d(0, -$super-height, 0)!important; } I'll be honest, I really don't lose much sleep over using !important. Embracing Repetition I think it's important to deal with a possible 'elephant in the room'. I need to try and convince you that eliminating repetition of properties and values across files may not buy as much, from a maintenance perspective, as a solid and contained set of modules that are easy to remove from a codebase as needed. The ECSS approach embraces repetition in the properties and values of the CSS. With ECSS, every single visual module or component is written with a micro-namespace to provide isolation from other modules and components. Here is a typical example of an authored ECSS rule (the authoring syntax is very similar to Sass, but typically facilitated by PostCSS): .ip-SubHeader_Wrapper { @mixin Headline; align-items: center; /* We want the subheader hidden by default on mobile */ display: none; font-size: $text12; background-color: $color-grey-54; border-bottom: 1px solid color($color-grey-54 a(.5)); min-height: $size-fine-quadruple; @include MQ(Mplus) { display: flex; background-color: $color-grey-a7; color: $color-grey-54; font-size: $text13; min-height: 1.5rem; border-bottom: 1px solid $color-grey-54; border-top: 1px solid $color-grey-33; } /* However, even on mobile, if the SubHeader Wrapper is in section 1, we want to see it */ .ip-Classification_Header-1 & { display: flex; } } Those inclined towards OOCSS and Atomic CSS methodologies may look at that and shudder. Things like colorand font-size are declared in most components. The @mixin Headline mixin generates a sizeable chunk of CSS to designate a particular font stack too. So, yes, there's repetition across styles. However, the positives: It's verbose yet it relies on nothing. It's generally context agnostic (save for the size context of where it is placed), any media queries that affect this component are defined within this single set of curly braces. A namespaced module is written once and once only. When this module needs to change, you only need to look in this one place. Writing rules with all overrides nested within creates a sort of micro-cascade. Where ordinarily overrides could be anywhere in the CSS, adhering to this method confines them to a very specific area. It then becomes far easier to reason about specificity as it relates to the rule. Zero component abstractions With ECSS, if a component needs to be made that is similar, yet subtly different to an existing component, we would not abstract or extend from this existing component. Instead, a new one would be written. Yes, I'm serious. Even if 95% of it is the same. The benefit of this is that each component is then independent and isolated. One can exist without the other. One can change however it needs to, independently from the other. Despite their apparent aesthetic similarity at the outset, they can mutate as needed with no fear of infecting or tainting any other similar looking component. To extend the biological metaphor, we have gained components that are 'self-quarantining' by virtue of their unique namespace. A further analogy: a BMW 3 series has a lot in common with a BMW 5 series. But they are not the same. They may share some/many parts (the equivalent of CSS property and value combinations) but that doesn't make them the same. Their differences define them. They cannot be made of exactly the same parts because there is something inherently different about them. I'd argue it is the same case with modules and components defined with ECSS. The CSS language IS the abstraction. The property/value pairs of CSS already mean we can build what we want from individual parts. The cost of repetition? To fully reap the benefits of ECSS you need to be comfortable with the property and value repetition it creates. At this point, you may believe me deluded. With all this duplication, how can this ECSS approach be a viable option? I'll address that concern with one word: gzip. OK, I lied. I'd like to qualify that further. gzip is incredibly efficient at compressing repetitive strings I was curious what 'real world' difference the verbosity of repeated property/value pairs in an approach like ECSS actually made? An experiment: A CSS file I was working on using the ECSS methodology, when gzipped (as it would be served 'over the wire'), was 42.9KB. The most common and verbose pattern that could be abstracted from this style sheet to an OOCSS class would be a couple of Flex based rules that are used abundantly throughout to vertically centre content within their container. They are even more verbose thanks to the fact that there is considerable code added by Autoprefixer to enable support on older devices. For example, the resultant CSS would be: .flex { display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; } In the test style sheet, those four lines of CSS were repeated 193 times. That's only half of it. Many of those items need aligning within. That required this in the CSS too: .flex-center { -webkit-box-align: center; -webkit-align-items: center; -ms-flex-align: center; align-items: center; } That block was repeated 117 times. Doesn't seem like any better reason to abstract to an OOCSS class, right? That must be causing some serious bloat right there? Not so fast, Batman! If those blocks of code were removed and the file re-gzipped, the CSS file size dropped to 41.9 KB. Extracting the most common and verbose visual pattern to an OOCSS class saved just 1KB of CSS over the wire. And despite just a 1KB saving in the CSS, factor in that if abstracting those styles to a class, it would also be necessary to litter the HTML with the relevant OOCSS classes to get the visual effect back. Was it worth it? Given that no other property combination had anything like that sort of verbosity and repetition, from a file size perspective, certainly not in my book. It would cost a lot of development agility (remember abstraction makes authoring and iteration slower as its necessary to change both templates and CSS) and responsive flexibility (what if I want this thing to do something different in a different viewport) for a minuscule gain in CSS weight. It's the CSS equivalent of 'robbing Peter to pay Paul'. Let me be quite clear. Despite the efficacy of gzip, if your priority is having the smallest possible CSS file size, ECSS isn't your best choice. Instead, go take a look at Atomic CSS. Its creators are smart people, indeed, Thierry Koblentzis one of the smartest CSSers I know of. I'm sure ACSS will serve your needs well. On the other hand, the priorities of ECSS are developer ergonomics (understandable class naming conventions), easy maintainability (styles organised by component and simple to delete) and style encapsulation (namespacing prevents leaky abstractions).

The problems of CSS at scale

The problems of CSS at scale In most projects, the CSS starts out with some simple rules. At the outset, you'd have to be doing something fairly daft to make maintenance of the CSS problematic. However, as the project grows, so too does the CSS. Requirements become more complicated. More authors get involved writing the styles. Edge cases and browser workarounds need to be authored and factored in. It's easy for things to get unruly fast. Let's consider the growing demands on a humble widget: "When the widget is in the sidebar, can we reduce the font size?" "When we're on the home page, can the widget have a different background colour?" "Can we have the things inside the widget stacked vertically at larger viewports?" "When the widget is in the sidebar on the product page, the font colour needs to change" Before long we need to write a whole raft of overrides to a base selector. Let's consider the selectors we might need: .widget { /* Base Styles */ } aside#sidebar .widget { /* Sidebar specific */ } body.home-page aside#sidebar .widget { /* Home page sidebar specific */ } @media (min-width: 600px) { .widget { /* Base Styles 600px and above */ } aside#sidebar .widget { /* Sidebar specific 600px and above */ } body.home-page aside#sidebar .widget { /* Home page sidebar specific 600px and above */ } } body.product-page .widget { /* Product page specific */ } body.product-page aside#sidebar .widget { /* Product page sidebar specific */ } There's some basic authoring problems there if this was CSS that we wanted to scale. Let's consider some of the more obvious problems in those rules now. Specificity The first major problem of CSS at scale is we want to by-pass the problem of specificity. Ordinarily, specificity is a useful thing. It allows us to introduce some form of logic in the CSS. Styles that are more specific than others get applied in the browser. Our example above demonstrates this: different rules will be applied in different eventualities (for example, when in the sidebar, we want to override the default styles). Now, CSS selectors can be made up of ID, class, attribute & type selectors and any combination of those. With responsive designs you can throw media queries into the mix too. However, not all selectors are created equal. The W3C describes how specificity is calculated here: http://www.w3.org/TR/css3-selectors/#specificity. Here is the most relevant section: A selector's specificity is calculated as follows: count the number of ID selectors in the selector (= a) count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b) count the number of type selectors and pseudo-elements in the selector (= c) ignore the universal selector Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class. Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity. One important thing missing there is the style attribute. Information on that elsewhere tells us that: The declarations in a style attribute apply to the element to which the attribute belongs. In the cascade, these declarations are considered to have author origin and a specificity higher than any selector. So, a style applied in a style attribute on an element is going to be more specific than an equivalent rule in a CSS file. Regardless, the biggest takeaway here is that ID selectors are infinitely more specific than class based selectors. This makes overriding any selector containing an ID based selector far more difficult. For example, with a widget in the sidebar this won't work: .widget { /* Widget in the sidebar */ } aside#sidebar .widget { /* Widget in an aside element with the ID of sidebar */ } .class-on-sidebar .widget { /* Why doesn't this work */ } In this instance we would be applying a HTML class (class-on-sidebar) on the sidebar element (the aside element with the ID of sidebar) and then selecting that in the CSS lower down than the ID based selector. However, the rule still won't be applied. Knowing what we know about specificity from the W3C specifications we can calculate the specificity of these rules. Let's run the numbers. Left to right, the numbers after the selectors below relate to: number of inline styles, number of ID selectors, number of class selectors, and finally the number of type selectors selectorinlineIDclasstype .widget0010 aside#sidebar .widget0111 .class-on-sidebar .widget0020 So you can see here that the middle selector has a greater specificity than the last. Bummer. On a single or smaller file, this isn't that much of a big deal. We just create a more specific rule. However, if the CSS of your codebase is split across many smaller partial CSS files, finding a rule that is preventing your override from working can become an unwanted burden. Now, the problem isn't specific to ID selectors. It's more of a problem with unequally weighted selectors in the style sheets. Think of it like a heavyweight boxer pitted against a flyweight. It's not a fair contest. Creating a level playing field across the selectors used is more important than the actual selectors used. This mis-matched soup of selectors is the crux of the specificity issue. As soon as you have a CSS codebase with hundreds of rules, any unneeded specificity starts to become a major 'pain in the ass' (that's a technical term). So, to conclude, specificity is a problem we need to address in an ever-growing CSS codebase. Markup structure tied to selectors Another typical faux pas when authoring large-scale CSS is using type selectors; selectors that relate to specific markup. For example: aside#sidebar ul > li a { /* Styles */ } In this case we need to have an 'a' tag inside an 'li' which is a direct child of a 'ul' inside an 'aside' element with an ID of 'sidebar' - phew! What happens if we want to apply those styles to a div somewhere else? Or any other markup structure? We've just unnecessarily tied our rule to specific markup structure. It's often quite tempting to do this, as it can seem ridiculous to add a class to something as (seemingly) trivial as an 'a' or 'span' tag. However, I hope once you reach the end of ECSS you'll be convinced to avoid the practice. The cascade Typically, the cascade part of CSS is useful. Even if specificity is very equal across the selectors used, it allows equivalent rules further down the CSS file to be applied over existing rules higher up. However, in a large codebase it becomes an unwanted safety net, allowing authors to continually add CSS to the codebase instead of amending the existing code. This can happen for a number of reasons. As an example, authors more familiar with other languages often lack the confidence or intimate knowledge of the CSS codebase to be able to confidently remove or amend existing code. They therefore take the safe option and override existing rules using a more specific set of rules. In practical terms this means adding the new rules, with whatever selectors are necessary to get the job done, to the bottom of the existing styles. The problem with leaning on the cascade in this way is that over time and iteration, the CSS code becomes bloated with redundant rules. The consumers of this CSS (the users) are downloading CSS full of cruft that their browser simply doesn't need

Immune web review

Who should read it? I recommend everyone who thinks that internet has an important place in there life to read this book. But more importantly this is a must read for: People who use social media on their smartphones Victims of cyber crime or someone who wants to know the source of spam mails Anyone concerned about how to use the web safely What’s in it for you? This guide will help you learn a lot of useful stuff which is all based on personal research & professional experience.  You’ll discover: How men are more insecure on net than women Why does reading terms & conditions matter What makes most passwords just stupid How a comment can take a life And a jumbo ride to the hidden world of Dark Web!

Pipeline

Pipeline

DBMS-Henry Korth(4th edition) Book

A complete solution of Database systems concepts by Abraham Silberschatz, Henry Korth & S. Sudarshan.

Operating system

About operating systems for btech students

Apache Spark

Architecture and Environment

Cloud Computing

Information about cloud computing