Tutorials on Css

CSS is and always has been a unique challenge. It's a tool that often divides developers into two camps: those who love it and those who kinda hate it. CSS can be an enigma even to the most skilled of devs. Developers able to create amazing pieces of code in Python and Node can be at a loss when learning how to buld CSS layouts.

If you’ve ever thought to yourself “man, CSS sucks !” when trying to build a layout, we have great news for you. We’re here to help you say goodbye to the frustration and confusion that often goes hand in hand with the little devil we like to call CSS. Introducing "Mastering CSS Layout" - the guide that promises to help you… uh… master CSS layout.

The best design and development teams imbue design and brand consistency across multiple products with design systems . When designers and developers collaborate on and regularly contribute to a design system, communication between designers and developers improves since a design system serves as a single source of truth for design guidelines, workflows and elements. By having a design system, everyone understands what set of colors, typography, components, etc. defines the brand and unifies the digital experience. A tool for building robust design systems is Figma . Unlike most other tools, Figma allows teams to work together on design systems in real-time. Design systems constantly evolve to meet users' growing expectations and/or adopt the latest UI/UX trends and patterns, so using a tool like Figma helps to organize, maintain and easily locate design elements. Plus, Figma provides an Inspect panel , which gives developers an easy way to extract CSS code from any design element. This close mapping to code makes developer handoff more seamless. Designers can edit styles and assets within the design system, and developers can view those changes immediately and quickly adapt them into the products. Pairing Figma with Storybook speeds up this process. With a single Storybook addon, storybook-addon-designs , a Figma design system (or any design system) gets directly embedded in the addon panel of the Storybook UI. Any updates made to the design system are synced to the Storybook addon, so developers don't have to switch back and forth between Figma and Storybook to implement these updates in code. They no longer need to ask for links to the updated parts of the design system.

Styled components redefine how we apply CSS styles to React components. Unlike the traditional approach of manually assigning CSS classes (from an imported CSS file) to elements within a component, CSS-in-JS libraries like styled-components provide primitives for locally scoping CSS styles to a component with unique, auto-generated CSS classes. Consider a simple <Card /> component composed of several styled React components. Each of styled 's helper methods corresponds to a specific DOM node: Here, the <Card /> component's styles, structure and logic can all be found within a single file. styled-components comes up with a unique class name for each set of CSS rules, feeds the CSS to a CSS preprocessor (Stylis), places the compiled CSS within a <style /> tag, injects the <style /> tag into the page and adds the CSS classes to the elements.

HTML , CSS and JavaScript form the foundation of all client-side applications. Each of these languages handles a different responsibility. HTML markup semantically organizes content, CSS rules styles content and JavaScript code adds dynamic interactivity to the content. Traditionally, developers build basic client-side applications along this standard separation of concerns, which groups code solely by language (and implicitly, by file type): HTML for structure, CSS for presentation and JavaScript for behavior. However, siloing code this way comes with a caveat. For example, if you have a carousel on your homepage, and you decide to modify its appearance, then you may need to consult three separate files ( .html , .css and .js files) to make the appropriate changes. With modern JavaScript libraries/frameworks, such as React , the separation of concerns shifts from languages to components. Now, all code belonging to a single component lives within a single file ( .jsx / .tsx for React). The component itself, written as a functional or class component, contains methods (lifecycle, render, etc.) that encapsulate its behavior. The JSX syntax within the render method (or within the return statement if written as a function) describes the component's structure. As for the component's presentation, there are two common approaches: Large CSS stylesheets are difficult to maintain, especially when tracking which rules override others and which rules can/cannot be removed. If you write styles using a CSS-in-JS library, then all styles belonging to a component exists alongside the component within a .jsx / .tsx file (or .js file if imported from a separate file). When the component is no longer used within the application, then deleting the component's styles is as simple as deleting the component itself.

Photo by  Mika Baumeister  on  Unsplash Most modern frameworks, like React, use components as their foundation. They do this for a few reasons, but a crucial one is that components allow you to break your app into simple single-purpose parts that can then be composed together to solve more complex needs. Unfortunately, CSS was invented to solve problems from the top down,  starting with more general rules to more specific rules . Components encourage you to start from the bottom up, breaking your pages down into the more specific parts first, often in isolation to the whole, and then composing them together. 

When faced with a need to visualise data, many developers' first instinct is to reach for a 3rd-party charting library. There's nothing wrong with this: there are several robust and full-featured libraries out there, and it's usually smart to leverage existing, good quality code. But we shouldn't forget that Angular, coupled with modern CSS features, also provides a great base on which to create our own, bespoke visualisation components. Doing so gives us the ability to tailor them to our exact use-cases, and avoid the inevitable trade-offs and bloat that comes with trying to solve for the general case of visualisation and charting. Also, creating visualisation components is just plain fun. In this article, we'll explore the process of creating a bar chart component for Angular. Even if you've created similar components before, the approach here might surprise you. We won't be rendering to a canvas element, or to dynamic SVG. We won't be using D3, or any dependencies besides those that come with a standard Angular CLI app. We won't be using any listeners or polling to detect resizes and run complex and flaky layout code. Instead, we'll strive to use modern CSS features, in particular grid and custom properties, to build the component's layout in a declarative and automatically responsive way. The finished chart can be viewed in this simple demo , or in a more complex demo .