Sass vs. SCSS: which syntax is better?

Leave a Comment

Since the creation of Sass nearly 5 years ago, it has been plagued by many levels of controversy. It billed itself as “a better CSS” and added brand new features unheard of to CSS authors such as variables, nesting and mixins. Sass also introduced an entirely different indentation-oriented syntax and a brand new perspective on how to author CSS.

The Sass syntax

The indented syntax of Sass was inherited from its first-born brother Haml. And while Sass and Haml once got along – Hey, they even shared the same Ruby Gem! – dissension in the family caused the two languages to split and go their separate ways. Each seeking its own fame and fortune in the land of Open Source opportunity.

One common objection among Sass detractors is that the indented syntax is so foreign to CSS. Why spend the time learning a language that is radically different from CSS? This difference, they fear, will make it hard for them to continue to remain fluent in a language with as many nuances and subtleties as CSS.

What if Sass is just a fad? What if it doesn’t last? What if it doesn’t gain traction among the masses? What if all their code and newly formed best practices fall by the wayside should the “downfalls” of Sass become a reality? What if … ah, you get the point.

And the objections trail on …

SCSS to the rescue!

In version 3 of Sass, the SCSS (Sassy CSS) syntax was introduced as “the new main syntax” for Sass and builds on the existing syntax of CSS. It uses brackets and semi-colons just like CSS. It doesn’t care about indentation levels or white-space.

In fact, Sass’s SCSS syntax is a superset of CSS – which means SCSS contains all the features of CSS, but has been expanded to include the features of Sass as well. In layman’s terms, any valid CSS is valid SCSS. And in the end, SCSS has the exact same features as the Sass syntax, minus the opinionated syntax.

Those who are new to Sass have less to learn. And as for Sass detractors, well, they can no longer complain about the syntax. As far as I’m concerned, SCSS is the new CSS.

Which syntax is better?

If you are an old hat at Sass, chances are you’ve got an opinion about which syntax is better. And there are a lot of good people on both sides of the aisle. Some prefer Sass, the original syntax – while others prefer SCSS. Either way, there’s no need for panic or worry because Sass’s indented syntax has not been and will never be deprecated!

I’m not even going to pretend to be unbiased in this debate. I myself am a huge fan of SCSS. A recent convert, actually. I was once a die-hard fan of the indented syntax, but I’ve changed my mind on the matter and I wrote this article to share why.

Before I get to that, let me explain the reasons I loved Sass, and why I almost didn’t give SCSS a chance.

Pros for Sass

Reason #1: The Sass syntax is more concise

It’s true. The indented syntax removes the need for semi-colons and braces. It doesn’t require that you use the verbose @include to mixin your mixins. Instead it uses the + operator which requires less typing and makes your code simpler, and easier to read.

Reason #2: The Sass syntax is easier to read

Because of its rules about indentation, it’s kind of hard to write unreadable Sass. Sass forces you to write your code the same way every time. There’s no option for venturing off and making your own style of commenting and formatting. It’s very strict on how things can be done. On large teams or in situations where you aren’t the sole author of all the code, this could be a huge plus. It forces the team into more strict coding practices (much like what XHTML did for HTML) and leaves little room for deviation from the beaten path.

Reason #3: The Sass syntax doesn’t complain about missing semi-colons

Ok, I know this probably belongs with reason #1, but I’m listing it separately because it was one of the major reasons I loved the original syntax. Not only did I not have to type semi-colons at the end of every attribute/value pair, but Sass ensured that my output always had the correct semi-colon placement. This is a huge win over writing vanilla CSS which doesn’t complain about semi-colons (but, the CSS validator does). When I wrote straight CSS I was always surprised by how many times a misplaced semi-colon was the reason a rule didn’t get applied properly.

This isn’t a points war

Now, before I get too far ahead of myself, I just want to say that this article isn’t a 3 points for Sass, 8 points for SCSS argument. Sure, I list more points for SCSS, but your feelings on each of the points are going to vary. For some, the three points I’ve stated above as pros for Sass will be persuasive enough to keep you using it. For many, switching back to something more like CSS after using Sass will seem like lunacy.

For me that’s exactly what it felt like the first time I tried to do a project in SCSS. The brackets and semi-colons were back. A lot of what I hated about CSS was back. It was like taking a step backwards instead of continuing to push forward (that’s the point right?).

In fact, like any good citizen of the Internet, I tweeted my hatred of SCSS. I had dipped my toes in the water and found it too chilly for my taste. So I hung up my curly-braces and semi-colons and went on my way. Sass was good enough for me just as it was, thank you very much. No need to revert back to the dark ages of CSS just to get a more familiar syntax.

A change of heart?

So, what changed my heart? To tell you the truth I’m not really sure. A lot of it for sure had to do with the fact that my good friend Brandon Mathis had recently made the switch to SCSS and felt it was better. Though he offered a couple of sound arguments, which I’ve reused below, Brandon really didn’t try to persuade me too much. Mainly, he just said that he had found he liked it better. It took him a while, of course, but he was much happier now that he had made the switch.

Now Brandon has probably written more Sass than almost anyone I know. He’s on the Compass core team and has been using Sass exclusively in his projects for over 4 years now. Needless to say, his opinion holds a lot of weight with me. Also, Chris Eppstein (the author of Compass) seems to prefer the SCSS syntax. He likes it so much, that he even rewrote all of Compass in it.

I was beginning to question my resolve. So on my next project, instead of giving it a half-hearted try for a day, I decided to go all in and code the whole project in SCSS to compare the difference. The outcome? I found that it took some getting used to (as expected), but I actually began to prefer the new SCSS syntax to the original Sass syntax.

Here’s why …

Pros for SCSS

Reason #1: SCSS is more expressive

No really! I know I argued above that Sass is easier to read because of the way it forces you to write your rules and attributes with indentation, but after coding for a while in SCSS I’ve realized that I really like having the option to put a couple of attribute/value pairs on the same line. I don’t always write it this way.

Normally, I write in expanded format with an attribute/value pair per line. But the compressed syntax is helpful when I only have an attribute/value pair or two. I especially like it for changing the color of a font for a hover state or adding an underline to a link.

For me SCSS ends up being more logically grouped than Sass. I can compress code that would take several lines in the Sass syntax into just a couple of lines of SCSS. Typically rules are grouped anyway. And when reading code, the number of lines of code that a bit of code uses tends to indicate its importance.

In SCSS I can compress lines that are fairly standard. And expand across several lines when I’m doing something complicated.

Reason #2: SCSS encourages proper nesting of rules

One of the huge advantages of Sass in general is that it allows you to nest selectors within selectors. This is awesome because when you change the “name” of an element, you only need to change it in one place (the outer selector) instead of in numerous places like you would when writing CSS.

But to quote Spiderman, with great power comes great responsibility.

And with the Sass syntax it really is true. It is too much power. At least for someone like me. Sass code I write tends to get too deeply nested. Why? Because it’s too easy to do. Every-time you nest something in Sass you need to be conscious of the impact that it is having on your output code.

Deeply nested Sass produces CSS with really long selectors. Especially if you use the comma operator at a high level (which is probably the most dangerous aspect of nesting). Not only is this bad because it increases the file size of the final CSS, too much specificity can become really hard to override in other rules. Importance is the result. You find yourself using !important in anger with fists in the air just to get a rule applied correctly.

Reason #3: SCSS encourages more modular code with @extend

Because nesting is harder in SCSS I find myself using @extend a lot more frequently. I tend to write code that is nested 1 – 2 levels deep underneath an abstract or virtual class name that is then extended by other selectors. Again, the curly braces, which are “ugly”, help me recognize when my code is too deeply nested and force me down the path of writing more modular code.

Oh, and if you’re not using the @extend directive, you are really missing out on the awesome-sauce of Sass! Experts agree. 🙂

Reason #4: SCSS allows me to write better inline documentation

It’s true that the Sass syntax allows a certain amount of flexibility with comments, but I find myself writing more inline-documentation directly in SCSS than Sass. A lot of this has to do with the way the code hangs together and the flexibility in syntax that SCSS provides. Braces help me group my code and comments in a way that makes more sense to me. I know we are talking aesthetics here, but more flexibility makes a difference when writing documentation.

Reason #5: Existing CSS tools often work with SCSS

I don’t actually use a lot of other tools with my CSS, but one area where this is particularly helpful is syntax highlighting. Depending on your editor preference, it may or may not have support for the indented Sass syntax. But most editors already have built-in support for CSS and tend to work well with SCSS. Also, if you do any blogging, most code highlighters support CSS, but only a handful support the Sass syntax.

Reason #6: Integration with an existing CSS codebase is much easier

I’ve often had to integrate with other CSS code when building a web site. It’s either code from some jQuery library I’m using, or a pre-existing CSS codebase. In the past I’ve often converted that code to Sass and lost valuable hours in the conversion process.

For a library, the downside is that it’s not code that you really want to maintain. When upgrading the library, the last thing you want to do is to go through the conversion process again. If it’s an existing codebase, it’s often much better to make smaller changes, than to jump into a megalithic refactoring process right away.

SCSS lets you use the existing code as is, and incrementally re-factor as you go along.

It’s true that with the indented syntax the sass-convert tool can get you most of the way there, but it’s never a completely clean conversion.

Reason #7: SCSS provides a much lower barrier to entry

From a Sass advocacy perspective, it’s much easier to convince someone to use SCSS than Sass. It’s easier to introduce them to a couple new concepts (SCSS) rather than an entirely new syntax. Designers can be very stubborn, caggy people. They are opinionated, and wary of change. They tend to do what they know well and while they do experiment with new things, experimentation with new technology is not built into the design community like it is for the programming community.

And don’t forget the other barriers to getting started with Sass. Right now you need to be familiar with the command prompt. At least enough to run a couple of commands. The command prompt is scary to the mouse-driven, button clicking designer.

Reason #8: SCSS could become the next version of CSS

Since its creation Sass and languages like it have attracted the attention of a lot of smart people. Some of those people are already thinking about adding some of the features that Sass introduced to CSS. It’s possible that the syntax introduced in SCSS could become CSS4!

Conclusion

I hope I’ve challenged you a little in your own perspective on both syntaxes. While I’m clearly arguing the advantages of the SCSS syntax, I’d also like to encourage you to go outside of your comfort zone and experiment a little more. If you’ve only been exposed to the SCSS syntax, perhaps you’d enjoy spending some time with the indented Sass syntax. And if you’re an original-flavor-only kinda person – a purist – you may benefit from giving the SCSS syntax a serious try.

As I said before, there are a lot of good people on both sides of the line in this debate. Feel free to express your own opinion in the comments below.

Editor’s Note

We’ve also setup a Wrangl to make sense of both sides of the argument.

Naturally Flow and the “Box” Problem

Leave a Comment

 

 The design philosophy described in the video emphasizes a profound understanding of space, both physical and digital, paralleling the architectural vision of Frank Lloyd Wright. By viewing the screen as a viewport into a vast virtual landscape, we can transcend the limitations of traditional UI design, allowing for a more immersive and intuitive user experience.

Expanding the Design Canvas

In this approach, the design canvas extends beyond the confines of a flat screen. It recognizes that our digital environments can emulate the depth and complexity of the physical world. Just as Wright’s architecture considers the arrangement of rooms to create fluidity and harmony, digital design should facilitate the natural flow of content. This perspective allows for multiple axes of interaction, enabling us to position information in ways that enhance accessibility and engagement.

Content-Driven Design

The arrangement of content should not be arbitrary. Instead, it should be driven by the nature of the content itself, promoting clarity and purpose. The form should emerge organically from the function, rather than being dictated by trends or aesthetic whims. This principle resonates with Wright’s philosophy of organic architecture, where each element serves a distinct purpose and contributes to the whole.

Case Study: SpaceX Tool

A practical illustration of this philosophy can be seen in the tool developed by SpaceX for designing rocket components. This tool eschews cluttered interfaces, opting instead for a layout that presents information contextually. As engineers focus on specific engine components, relevant data appears seamlessly within their workspace. This contextual relevance mirrors the open spaces in Wright’s designs, allowing for unobstructed creativity and efficient workflow.

Intuitive Interaction

To enhance the user experience further, SpaceX utilizes the Leap Motion Controller, which allows engineers to interact with the design using natural hand movements. This approach embodies the idea of sculpting rather than merely clicking or tapping, making the experience more intuitive and aligned with human gestures. By integrating such technology, the design not only adheres to Wright’s principles but also emphasizes the importance of material usage and functional simplicity.

Conclusion

In summary, the digital design process should aspire to create environments that feel expansive and natural, echoing the principles of organic architecture. By prioritizing content, context, and intuitive interaction, we can craft user experiences that are not just functional but also deeply engaging. Just as Wright’s structures harmonized with their surroundings, so too should our digital interfaces resonate with the needs and behaviors of their users, fostering an organic flow of information and interaction.

OOCSS Principles, why even bother?

Leave a Comment

Object-Oriented CSS (OOCSS) is a methodology that applies object-oriented principles to CSS to enhance both the performance and maintainability of stylesheets. By encouraging code reuse and modular design, OOCSS seeks to reduce repetition and streamline development, making stylesheets easier to scale and maintain.

Key Principles of OOCSS

  1. Separation of Structure and Skin
    • Structure refers to properties like width, height, margins, padding, and positioning.
    • Skin refers to visual properties like colors, fonts, borders, and shadows.
    • By separating these, you can reuse structure-related styles across various elements while applying different skins to customize their appearance.
  2. Separation of Containers and Content
    • Styles should be independent of the specific container in which they are used, allowing them to be reused across different parts of a webpage.
    • Avoiding descendant selectors and styling based on container contexts helps make your CSS more modular.

Benefits of OOCSS

  1. Faster Websites: Reducing repetitive styles results in smaller CSS files, which load faster.
  2. Scalability: You can reuse styles easily as your project grows, making it simpler to scale CSS for large applications.
  3. Maintainability: Modular styles are easier to track, debug, and modify. When new developers join a project, they can extend or reuse existing styles without creating complex or conflicting rules.
  4. Efficiency: Having less code to maintain and apply makes development quicker and more efficient.
  5. Readability: Well-structured OOCSS makes it easier for other developers to understand your code.

Example of Applying OOCSS

Instead of repeating styles for multiple elements, OOCSS encourages you to abstract common styles into reusable classes.

Before OOCSS:

#button {
    width: 200px;
    height: 50px;
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
#box {
    width: 400px;
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
CSS

After OOCSS:

.button {
    width: 200px;
    height: 50px;
}

.box {
    width: 400px;
}

.skin {
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
CSS

Now, you can apply the skin class to multiple elements to reuse the visual properties.

Understanding Object-Oriented CSS (OOCSS)

As web development continues to evolve, the complexity of managing CSS grows with it. With the rise of interactive web applications and intricate designs, developers are increasingly turning to methodologies that offer more structure and maintainability to their stylesheets. One such methodology is Object-Oriented CSS (OOCSS), proposed by web developer Nicole Sullivan in 2008. OOCSS applies principles from object-oriented programming to CSS, allowing developers to create reusable, scalable, and maintainable styles. This article delves into the core principles of OOCSS, its advantages and disadvantages, and how it can significantly improve the performance and maintainability of web pages.

The Principles of OOCSS

At the heart of OOCSS are two main principles: the separation of structure from skin, and the separation of containers from content.

1. Separation of Structure from Skin

The first principle of OOCSS focuses on distinguishing between the structural properties of an element and its visual properties. In web design, structure refers to the layout aspects of an element, such as size, padding, and positioning, while skin refers to the aesthetic aspects, such as color, font, and texture. By separating these two aspects, developers can create modular components that can be reused across different contexts.

Example:

Before OOCSS Implementation:

.button {
    width: 150px;
    height: 50px;
    background: #FFF;
    border-radius: 5px;
}

.button-2 {
    width: 150px;
    height: 50px;
    background: #000;
    border-radius: 5px;
}
CSS

In the above code, there is a lot of repetition, particularly in defining width, height, and border-radius.

After OOCSS Implementation:

.skin {
    width: 150px;
    height: 50px;
    border-radius: 5px;
}

.button {
    background: #FFF;
}

.button-2 {
    background: #000;
}
CSS

Here, the structural styles are abstracted into a reusable .skin class, which can be combined with different skin classes. This reduces redundancy and makes it easier to manage the CSS.

2. Separation of Containers from Content

The second principle emphasizes separating the styling of containers from their content. This ensures that styles applied to elements are not overly dependent on their parent containers, which enhances reusability and predictability.

Example:

Before OOCSS Implementation:

#sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}

#sidebar .list {
    margin: 3px;
}

#sidebar .list .list-header {
    font-size: 16px;
    color: red;
}

#sidebar .list .list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}
CSS

In this example, the styles are tightly coupled with the #sidebar container, making it difficult to reuse the .list, .list-header, and .list-body classes outside of that context.

After OOCSS Implementation:

.sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}

.list {
    margin: 3px;
}

.list-header {
    font-size: 16px;
    color: red;
}

.list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}
CSS

With OOCSS, the container and content styles are defined independently. This modular approach allows developers to reuse styles more effectively across different components, regardless of their context in the document.

Advantages of OOCSS

The benefits of adopting OOCSS are manifold, especially for larger projects where CSS can quickly become complex and unwieldy.

1. Faster Websites

By minimizing repetitive styles, OOCSS helps reduce the size of CSS files. Smaller stylesheets lead to faster download times, improving the overall performance of web pages. Although it may introduce a slight increase in the HTML file size due to additional class attributes, the performance gains from optimized stylesheets often outweigh this drawback.

2. Maintainable Stylesheets

OOCSS encourages the creation of a maintainable stylesheet by reducing specificity conflicts and fostering a modular approach. Rather than creating unique styles for each component, developers can leverage existing modules, making updates and additions much easier. As projects evolve, new components can be built on top of existing styles, ensuring consistency and reducing the likelihood of introducing bugs.

3. Scalability

OOCSS supports scalable design by allowing developers to reuse style modules across various elements. As a project grows, developers can freely combine and reapply classes without worrying about specificity or conflicts. This is particularly beneficial in larger teams where different developers may work on different components.

4. Enhanced Readability

With its focus on modular design, OOCSS makes CSS more readable. Other developers can quickly understand the structure and intent of the styles, which is crucial for collaboration. Clear naming conventions and organized class structures improve communication and reduce the learning curve for new team members.

5. Efficiency

Fewer lines of code mean that developers can scan and edit styles more efficiently. When styles are defined once and reused, the development process becomes more streamlined, allowing for quicker iterations and modifications.

6. Reduced Duplication of Efforts

By following the DRY (Don’t Repeat Yourself) principle, OOCSS eliminates redundant styles. This not only saves time but also reduces the chances of inconsistencies that can arise when multiple developers inadvertently create similar styles.

Disadvantages of OOCSS

While OOCSS offers numerous benefits, it is not without its challenges. Developers should be aware of these potential downsides when considering its implementation.

1. Learning Curve

For developers unfamiliar with object-oriented programming principles, adapting to OOCSS can take time. Understanding the concepts of separation and modularity may require a shift in mindset, especially for those accustomed to traditional CSS practices.

2. Increased HTML Markup

One criticism of OOCSS is that it can lead to more cluttered HTML markup due to the increased use of classes. This can make the HTML harder to read, particularly in simpler projects where a lightweight structure is preferable. However, the trade-off is often worthwhile for larger applications where maintainability and performance are critical.

3. Overhead for Small Projects

For smaller projects or simple static sites, the overhead of implementing OOCSS may not be justified. In such cases, a more straightforward approach might be sufficient, as the benefits of modular CSS become more apparent in larger, more complex applications.

4. Potential for Over-Engineering

In an effort to adhere to OOCSS principles, developers might over-engineer their CSS, creating unnecessary abstractions. It is essential to strike a balance between modularity and simplicity, ensuring that styles remain straightforward and easy to understand.

Real-World Example: Applying OOCSS

To illustrate how OOCSS can be effectively applied in a real-world scenario, consider the design of a web page featuring multiple button styles and layout containers.

Initial CSS (without OOCSS):

.button-primary {
    width: 120px;
    height: 40px;
    background-color: blue;
    color: white;
    border-radius: 5px;
}

.button-secondary {
    width: 120px;
    height: 40px;
    background-color: grey;
    color: black;
    border-radius: 5px;
}

.container {
    width: 960px;
    margin: 0 auto;
    padding: 20px;
}
CSS

In this example, the button styles are not reusable, leading to duplication of properties.

Refactored CSS (with OOCSS):

.button {
    width: 120px;
    height: 40px;
    border-radius: 5px;
}

.button-primary {
    background-color: blue;
    color: white;
}

.button-secondary {
    background-color: grey;
    color: black;
}

.container {
    width: 960px;
    margin: 0 auto;
    padding: 20px;
}
CSS

By introducing a base .button class for shared properties, the code becomes more modular and maintainable.

Guidelines for Implementing OOCSS

Getting started with OOCSS may require some adjustments to your development practices. Here are a few guidelines to help you transition to an OOCSS mindset:

  1. Avoid Descendant Selectors: Focus on using class-based selectors rather than descendant selectors to ensure styles are reusable.
  2. Favor Classes Over IDs: Rely primarily on classes for styling rather than IDs, as classes provide more flexibility and avoid specificity issues.
  3. Modularize Styles: Identify repeating patterns in your CSS and create reusable modules that can be applied across different elements.
  4. Use Naming Conventions: Establish clear naming conventions for classes that reflect their purpose and usage, improving readability and maintainability.
  5. Utilize Tools: Consider using tools like CSS Lint to check for code quality and adherence to OOCSS principles.

Conclusion

Object-Oriented CSS (OOCSS) is a powerful methodology that can significantly enhance the performance, maintainability, and scalability of web stylesheets. By embracing the principles of separation of structure from skin and separation of containers from content, developers can create modular, reusable components that streamline the development process. While OOCSS may not be suitable for every project, particularly smaller ones, its advantages become increasingly apparent as web applications grow in complexity. By adopting an OOCSS approach, developers can produce faster, more efficient, and easier

Design Form and function as One Unit

Leave a Comment

To compare and contrast the philosophies of Louis Sullivan and Frank Lloyd Wright regarding the relationship between form and function in architecture, let’s break down the key points and elaborate on their significance:

Louis Sullivan: “Form Follows Function”

  1. Core Principle: Sullivan famously stated that “form ever follows function,” emphasizing that the design of a building should be primarily guided by its intended use. In Sullivan’s eyes, function was paramount, and aesthetic qualities should naturally evolve from this primary function.
  2. Architectural Clarity: For Sullivan, this principle meant that the structure of the building should clearly express its purpose. For example, the design of tall office buildings during the early 20th century should reflect their role as spaces for productivity and commerce, often resulting in designs that highlighted verticality and functionality.
  3. Historical Context: Sullivan’s ideas can be traced back to the early Roman architect Vitruvius, who espoused that buildings should be “firm, useful, and beautiful.” Sullivan appropriated these principles and articulated them in the context of modern architecture, focusing on how buildings should serve societal needs.

Frank Lloyd Wright: “Form and Function Should Be One”

  1. Philosophical Evolution: Wright built upon Sullivan’s ideas but offered a broader interpretation. He argued that “form and function should be one joined in spiritual union,” suggesting that the two elements are not distinct but rather intertwined in a harmonious relationship.
  2. Aesthetic Flexibility: This philosophy allowed Wright the creative liberty to innovate beyond strict functionalism. While maintaining practicality, he emphasized the aesthetic qualities of architecture, leading to designs that were not only functional but also deeply expressive. His buildings often echoed the landscape and blended into their environment, as seen in works like Fallingwater.
  3. Human Experience: Wright’s approach also placed importance on the human experience within architecture. He believed that spaces should be designed not just for utility but also to evoke emotions and connections with the surrounding environment. This led to organic architecture—designs that emphasize harmony between human habitation and nature.

Comparative Analysis

  • Function vs. Aesthetic Integration: While Sullivan focused on functionality dictating form, Wright considered both aspects as interdependent. Sullivan’s designs might prioritize function at the risk of aesthetic monotony, whereas Wright’s philosophy encouraged a more balanced approach that celebrated both functionality and artistic expression.
  • Historical Context: Both architects drew influence from Vitruvius, yet their interpretations reflect different historical contexts—Sullivan during the rise of industrialism and urbanization, and Wright amidst growing movements toward modernization and environmental harmony.
  • Legacy and Influence: Sullivan’s phrase continues to resonate in modern architecture, where functionality remains a key concern. Wright’s inclusive approach paved the way for the development of various architectural styles, encouraging architects to explore the emotional and philosophical dimensions of their work.

Conclusion

In essence, while Louis Sullivan’s mantra of “form follows function” emphasizes practicality and clarity, Frank Lloyd Wright expanded this dialogue to encompass a holistic vision where form and function exist in a symbiotic relationship. Their legacies continue to influence architects today, providing a spectrum of philosophies on how best to approach design in an ever-evolving world. Wright’s adaptation ultimately promotes a deeper understanding of the impact of architecture on human experience and the environment.

OOCSS

Leave a Comment

OOCSS (Object-Oriented CSS) is a methodology for writing scalable, maintainable, and reusable CSS. Introduced by Nicole Sullivan, OOCSS encourages developers to think of their CSS as objects, promoting separation of structure and skin, as well as modular design principles.

Key Principles

  1. Separation of Structure and Skin:
    OOCSS distinguishes between the structural (layout-related) and skin (visual styles like colors, fonts, or backgrounds) properties of an element. This ensures better reusability by enabling designers to update visual styles independently of the layout.
    • Example:
      .box {
    padding: 20px;
    border: 1px solid #ccc;
}
.box-skin {
    background-color: #f4f4f4;
    color: #333;
}
      CSS
  2. Separation of Containers and Content:
    OOCSS treats the styling of content and its container as separate entities. This way, content can be styled independently of the layout, improving adaptability to various contexts.
<div class="box box-skin"></div>
HTML

Benefits

  • Reusability: Classes can be reused across multiple components or pages, reducing redundancy in your CSS.
  • Scalability: Modular, object-based styles are easier to scale as your project grows.
  • Consistency: By defining reusable objects, you ensure consistent styling across your application.
  • Maintainability: Isolated changes in one “object” do not ripple across unrelated styles, making the CSS easier to maintain and debug.

OOCSS in Practice

  1. Define Reusable Objects:
    Focus on creating reusable classes for recurring patterns (e.g., buttons, cards, grids).
    .btn {
    padding: 10px 20px;
    border-radius: 5px;
}
.btn-primary {
    background-color: #007bff;
    color: white;
}
    CSS
  2. Avoid Overly Specific Selectors:
    Favor classes over deeply nested selectors or IDs. This simplifies reuse and reduces specificity wars.
    /* Bad */
#header .nav ul li a {
    color: red;
}

/* Good */
.nav-link {
    color: red;
}
    CSS
  3. Combine Classes:
    Combine small, single-purpose classes for flexibility instead of creating monolithic styles.
    <div class="box box-skin"></div>
    HTML
  4. Use Naming Conventions:
    OOCSS often complements naming methodologies like BEM (Block-Element-Modifier) for clarity.

Limitations

  • Initial Complexity: Adopting OOCSS requires a shift in mindset, which may be challenging for teams unfamiliar with it.
  • Overhead: Excessive class names or overly abstracted objects can result in bloated HTML.

Conclusion

OOCSS promotes a modular approach to CSS by treating styles as reusable objects. By separating structure from skin and container from content, OOCSS enhances scalability, maintainability, and efficiency. While it may require upfront planning and discipline, the long-term benefits make it a valuable tool for modern web development.

CSS Gradients

Leave a Comment

Just as you can declare the background of an element to be a solid color in CSS, you can also declare that background to be a gradient. Using gradients declared in CSS, rather using an actual image file, is better for control and performance. Gradients are typically one color that fades into another, but in CSS you can control every aspect of how that happens, from the direction to the colors (as many as you want) to where those color changes happen. Let’s go through it all.  

Gradients are background-image

While declaring the a solid color uses background-color property in CSS, gradients use background-image. This comes in useful in a few ways which we’ll get into later. The shorthand background property will know what you mean if you declare one or the other.
.gradient {

  /* can be treated like a fallback */
  background-color: red;

  /* will be "on top", if browser supports it */
  background-image: linear-gradient(red, orange);

  /* these will reset other properties, like background-position, but it does know what you mean */
  background: red;
  background: linear-gradient(red, orange);

}

Linear Gradient

Perhaps the most common and useful type of gradient is the linear-gradient(). The gradients “axis” can go from left-to-right, top-to-bottom, or at any angle you chose. Not declaring an angle will assume top-to-bottom:
.gradient {
  background-image:
    linear-gradient(
      red, #f06d06
    );
}
Those comma-separated colors can type of color you normally use: Hex, named colors, rgba, hsla, etc. To make it left-to-right, you pass an additional parameter at the beginning of the linear-gradient() function starting with the word “to”, indicating the direction, like “to right”:
.gradient {
  background-image:
    linear-gradient(
      to right, 
      red, #f06d06
    );
}
This “to” syntax works for corners as well. For instance if you wanted the axis of the gradient to start at the bottom left corner and go to the top right corner, you could say “to top right”:
.gradient {
  background-image:
    linear-gradient(
      to top right, 
      red, #f06d06
    );
}
If that box was square, the angle of that gradient would have been 45°, but since it’s not, it isn’t. If you wanted to make sure it was 45°, you could declare that:
.gradient {
  background-image:
    linear-gradient(
      45deg, 
      red, #f06d06
    );
}
You aren’t limited to just two colors either. In fact you can have as many comma-separated colors as you want. Here’s four:
.gradient {
  background-image:
    linear-gradient(
      to right, 
      red, 
      #f06d06, 
      rgb(255, 255, 0), 
      green
    );
}
You can also declare where you want any particular color to “start”. Those are called “color-stops”. Say you wanted yellow to take up the majority of the space, but red only a little bit in the beginning, you could make the yellow color-stop pretty early:
.gradient {
  height: 100px;
  background-color: red;
  background-image:
    linear-gradient(
      to right,
      red,
      yellow 10%
    );
}
We tend to think of gradients as fading colors, but if you have two color stops that are the same, you can make a solid color instantly change to another solid color. This can be useful for declaring a full-height background that simulates columns.
.columns-bg {
  background-image:
    linear-gradient(
      to right, 
      #fffdc2,
      #fffdc2 15%,
      #d7f0a2 15%,
      #d7f0a2 85%,
      #fffdc2 85%
    );
}

Browser Support / Prefixes

So far we’ve only looked at the new syntax, but CSS gradients have been around for quite a while. Browser support is good. Where it gets tricky is syntax and prefixing. There are three different syntaxes that browsers have supported. This isn’t what they are officially called, but you can think of it like:
  1. Old: original WebKit-only way, with stuff like from() and color-stop()
  2. Tweener: old angle system, e.g. “left”
  3. New: new angle system, e.g. “to right”
And then prefixing as well. Let’s try a chart:
Chrome1-9: Old, prefixed10-25: Tweener, prefixed26: New, unprefixed
Safari3-: No support4-5.0: Old, prefixed5.1-6.0: Tweener, prefixed 6.1: New, unprefixed
Firefox3.5-: No support3.6-15: Tweener, prefixed16: New, unprefixed
Opera11.0-: No support11.1-11.5: Tweener, prefixed, only linear11.6-12: Tweener, prefixed, added radial 12.1: Tweener, unprefixed 15: New, unprefixed
IE8-: No support9: filters only10+: New, unprefixed (also supports Tweener w/ prefix)
Android2.0-: No support2.1-3.0: Tweener, prefixed4.0-4.3: New, prefixed 4.4+: New, unprefixed
iOS3-: No support3.2-4.3: Tweener, prefixed5.0-6.1: New, prefixed 7.0: New, unprefixed
There is some overlap in there. For instance when a browser supports the New syntax they probably also support the older syntaxes as well, including the prefix. Best practice is: if it supports New, use New. So if you wanted to absolute deepest possible browser support, a linear gradient might look like this:
.gradient {
  
  /* Fallback (could use .jpg/.png alternatively) */
  background-color: red;

  /* SVG fallback for IE 9 (could be data URI, or could use filter) */
  background-image: url(fallback-gradient.svg); 

  /* Safari 4, Chrome 1-9, iOS 3.2-4.3, Android 2.1-3.0 */
  background-image:
    -webkit-gradient(linear, left top, right top, from(red), to(#f06d06));
  
  /* Safari 5.1, iOS 5.0-6.1, Chrome 10-25, Android 4.0-4.3 */
  background-image:
    -webkit-linear-gradient(left, red, #f06d06);

  /* Firefox 3.6 - 15 */
  background-image:
    -moz-linear-gradient(left, red, #f06d06);

  /* Opera 11.1 - 12 */
  background-image:
    -o-linear-gradient(left, red, #f06d06);

  /* Opera 15+, Chrome 25+, IE 10+, Firefox 16+, Safari 6.1+, iOS 7+, Android 4.4+ */
  background-image:
    linear-gradient(to right, red, #f06d06);

}
That’s an awful lot of code there. Doing it by hand would be error-prone and a lot of work. Autoprefixer does a good job with it, allowing you to trim that amount of code back as you decide what browsers to support. The Compass mixin can do SVG data URI’s for IE 9 if that’s important to you. To complicate things just a little more, the way degrees work in the OLD vs NEW syntax is a bit different. The OLD (and TWEENER – usually prefixed) way defines 0deg and left-to-right and proceeds counter-clockwise, while the NEW (usually unprefixed) way defines 0deg as bottom-to-top and proceeds clockwise. OLD (or TWEENER) = (450 – new) % 360 or even simpler: NEW = 90 – OLD OLD = 90 – NEW like: OLD linear-gradient(135deg, red, blue) NEW linear-gradient(315deg, red, blue)

IE filters

Internet Explorer (IE) 6-9, while they don’t support the CSS gradient syntax, do offer a programmatic way to do background gradients
/* "Invalid", but works in 6-8 */
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr=#1471da, endColorstr=#1C85FB);

/* Valid, works in 8-9 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#1471da, endColorstr=#1C85FB)";
There are some considerations here on deciding to use this or not:
  1. filter is generally considered a bad practice for performance,
  2. background-image overrides filter, so if you need to use that for a fallback, filters are out. If a solid color is an acceptable fallback (background-color), filter is a possibility
Even though filters only work with hex values, you can still get alpha transparency by prefacing the hex value with the amount of transparency from 00 (0%) to FF (100%). Example: rgba(92,47,90,1) == #FF5C2F5A rgba(92,47,90,0) == #005C2F5A

Radial Gradients

Radial gradient differ from linear in that they start at a single point and emanate outwards. Gradients are often used to simulate a lighting, which as we know isn’t always straight, so they can be useful to make a gradient seem even more natural. The default is for the first color to start in the (center center) of the element and fade to the end color toward the edge of the element. The fade happens at an equal rate no matter which direction.
.gradient {
  background-image:
    radial-gradient(
      yellow,
      #f06d06
    );
}
You can see how that gradient makes an elliptical shape, since the element is not a square. That is the default (ellipse, as the first parameter), but if we say we want a circle we can force it to be so:
.gradient {
  background-image:
    radial-gradient(
      circle,
      yellow,
      #f06d06
    );
}
Notice the gradient is circular, but only fades all the way to the ending color along the farthest edge. If we needed that circle to be entirely within the element, we could ensure that by specifying we want the fade to end by the “closest-side” as a space-separated value from the shape, like:
.gradient {
  background-image:
    radial-gradient(
      circle closest-side,
      yellow,
      #f06d06
    );
}
The possible values there are: closest-corner, closest-side, farthest-corner, farthest-side. You can think of it like: “I want this radial gradient to fade from the center point to the __________, and everywhere else fills in to accommodate that.” A radial gradient doesn’t have to start at the default center either, you can specify a certain point by using “at ______” as part of the first parameter, like:
.gradient {
  background-image:
    radial-gradient(
      circle at top right,
      yellow,
      #f06d06
    );
}
I’ll make it more obvious here by making the example a square and adjusting a color-stop:

Browser Support

It’s largely the same as linear-gradient(), except a very old version of Opera, right when they started supporting gradients, only did linear and not radial. But similar to linear, radial-gradient() has gone through some syntax changes. There is, again: “Old”, “Tweener”, and “New”.
/* Example of Old */
background-image: 
  -webkit-gradient(radial, center center, 0, center center, 141, from(black), to(white), color-stop(25%, blue), color-stop(40%, green), color-stop(60%, red), color-stop(80%, purple));

/* Example of Tweener */
background-image: 
  -webkit-radial-gradient(45px 45px, farthest-corner, #F00 0%, #00F 100%) repeat scroll 0% 0% rgba(0, 0, 0, 0);

/* Example of New */
background-image: 
  radial-gradient(circle farthest-side at right, #00F, #FFF);
The hallmarks being:
  • Old: Prefixed with -webkit-, stuff like from() and color-stop()
  • Tweener: First param was location of center. That will completely break now in browsers that support new syntax unprefixed, so make sure any tweener syntax is prefixed.
  • New: Verbose first param, like “circle closest-corner at top right”
Again, I’d let Autoprefixer handle this. You write in the newest syntax, it does fallbacks. Radial gradients are more mind-bending than linear, so I’d recommend attempting to just get comfortable with the newest syntax and going with that (and if necessary, forget what you know about older syntaxes).

Repeating Gradients

With ever-so-slightly less browser support are repeating gradients. They come in both linear and radial varieties. There is a trick, with non-repeating gradients, to create the gradient in such a way that if it was a little tiny rectangle, it would line up with other little tiny rectangle versions of itself to create a repeating pattern. So essentially create that gradient and set the background-size to make that little tiny rectangle. That made it easy to make stripes, which you could then rotate or whatever. With repeating-linear-gradient(), you don’t have to resort to that trickery. The size of the gradient is determined by the final color stop. If that’s at 20px, the size of the gradient (which then repeats) is a 20px by 20px square.
.repeat {
  background-image: 
    repeating-linear-gradient(
      45deg,
      yellow,
      yellow 10px,
      red 10px,
      red 20px /* determines size */
    );
}
Same with radial:
.repeat {
  background: 
    repeating-radial-gradient(
      circle at 0 0, 
      #eee,
      #ccc 50px
    );
}

Improper Fallback Loading

As we’ve covered, some really old browsers don’t support any CSS gradient syntax at all. If you need a fallback that is still a gradient, an image (.jpg / .png) could do the trick. The scary part with that is that some slightly-less-old browsers, that were just starting to support CSS gradients, would load the fallback image. As in, make the HTTP request for the image even though it would render the CSS gradient. Firefox 3.5.8 did this (see screenshot), as well as Chrome 5- and Safari 5.0.1. See:
Safari 5.0.1 loading fallbacks improperly
The good news is this isn’t really any issue anymore. The only offending browsers were Chrome and Safari and Chrome hasn’t done it since 6 and Safari hasn’t done it as of 5.1, going on three years ago.

Additional Resources

SASS

Leave a Comment

SASS is css on steroids. I could say SASS is the natural evolution of CSS into a formal programming language and it falls somewhere in the middle.

Why use SASS?

  • Faster coding
    • mixin
  • Better organization
    • Nesting
    • @media
  • The ability to use math operators, variables, functions and control directives
  • Encoding
  • Output style

jQuery noConflict Wrappers

Leave a Comment

The jQuery library included with WordPress is set to the noConflict() mode (see wp-includes/js/jquery/jquery.js). This is to prevent compatibility problems with other JavaScript libraries that WordPress can link. In the noConflict() mode, the global $ shortcut for jQuery is not available, so you can still use:
jQuery(document).ready(function(){
    jQuery(#somefunction) ...
});
but the following will either throw an error, or use the $ shortcut as assigned by another library.
$(document).ready(function(){
     $(#somefunction) ...
});
However, if you really like the short $ instead of jQuery, you can use the following wrapper around your code:
jQuery(document).ready(function($) {
    // Inside of this function, $() will work as an alias for jQuery()
    // and other libraries also using $ will not be accessible under this shortcut
});
That wrapper will cause your code to be executed when the DOM is fully constructed. If, for some reason, you want your code to execute immediately instead of waiting for the DOM ready event, then you can use this wrapper method instead:
(function($) {
    // Inside of this function, $() will work as an alias for jQuery()
    // and other libraries also using $ will not be accessible under this shortcut
})(jQuery);
Alternatively, you can always reasign jQuery to another shortcut of your choice and leave the $ shorcut to other libraries:
var $j = jQuery;

Update Node.js Version

Leave a Comment

I was recently installing a utility via NPM when I learned that my version of Node.js itself was out of date.  No worries — simply upgrade my Node.js install and move forward.  Of course I could just hit nodejs.org and get the new image, but figured there had to be an easier way.  It turns out there is — you can upgrade your local Node.js with NPM:
sudo npm cache clean -f
sudo npm install -g n
sudo n stable
The n package represents a Node helper, and running the last command upgrades node to the latest stable version.  Instead of using “stable”, you could specify a desired version:
sudo n 0.8.21
Once your install is complete, you can confirm you version with another command:
node -v
It’s quite nice that you can upgrade Node.js right from npm;  it’s like Inception…or something.