DEV Community: i am message

Pixels, Tokens, and Grids: Speaking the Same Language in Design and Code

i am message — Tue, 02 Sep 2025 17:44:51 +0000

Design and development handoff is one of the most critical points in a product’s lifecycle. A design may look clean and polished in Figma, Sketch, or Adobe XD, but if the specifications handed off to developers are inconsistent—such as using fractional pixel values (13.7px, 22.4px, 47.2px) or icon sizes with decimals—it introduces friction, implementation errors, and long-term scalability problems.

This article explains why consistency in values matters, the technical issues caused by decimals and arbitrary sizing, and how they impact accessibility, developer experience, and the scalability of a design system.

The Role of Design Tokens

Modern front-end development relies heavily on design tokens. Tokens are named values representing design decisions:

Spacing: 4px, 8px, 16px, 32px
Typography: 12px, 14px, 16px, 20px, 24px
Colors: primary-500, neutral-200, etc.
Icons & Radius: multiples of 4 or 8

Tokens create a shared language between design and code. They ensure consistency, make global updates simple (e.g., updating brand colors or scaling typography), and eliminate arbitrary one-off values.

👉 When a designer specifies 23.7px padding or a 13.5px font size, it breaks this system. Developers cannot map those values to tokens and must either round them (losing fidelity) or create exceptions (increasing inconsistency).

Why Decimal Pixels Don’t Work

1. Rendering Inconsistency Across Devices

Web and native platforms rely on device-independent pixels (dp in Android, pt in iOS).
A fractional value like 13.5px doesn’t translate well into these units; it gets rounded differently depending on device pixel ratio (DPR).
Result: Slight misalignments, blurred icons, and inconsistent spacing across devices.

2. Icon Sharpness and Pixel Grid

Icons need to align perfectly to the pixel grid to render sharply.

A 23.7px icon will be anti-aliased (blurred edges).
Exporting icons at consistent whole sizes (16, 20, 24, 32px) ensures sharpness on all screens.

3. Scalability and Maintainability

Arbitrary decimals lead to CSS bloat: 23.7px, 47.2px, 11.3px all become unique rules.
This breaks the principle of reusable tokens → every new screen introduces exceptions.
When scaling designs (responsive layouts, theming, accessibility), inconsistencies multiply.

4. Cross-Platform Alignment

A design system must work across Web, iOS, and Android.

On iOS, pt values are integers.
On Android, dp/sp values are integers.
On Web, CSS pixels are integer-aligned per DPR.
Decimal values simply don’t exist natively, so developers must round → making the original design intent meaningless.

Accessibility Considerations

Accessibility (a11y) is often overlooked in the design-to-code pipeline, but inconsistent or fractional values can degrade accessibility in subtle but important ways:

Legibility of Text

Fonts sized at decimals (e.g., 13.5px) may render inconsistently across platforms.
On some browsers/devices, this causes text to appear slightly thinner or blurrier, impacting readability — especially for users with visual impairments.

Touch Targets and Hit Areas

Accessibility guidelines (WCAG, Apple HIG, Material Design) require minimum touch targets of 44×44px or 48×48dp.
A button with fractional padding or inconsistent sizing may fall short of these thresholds, making it harder for users with motor disabilities to tap reliably.

Zoom and Scaling

When users zoom or enable larger text settings, fractional values often compound rounding errors, leading to misaligned UI elements.
Sticking to consistent integer-based tokens ensures interfaces scale predictably.

👉 In short, clean integer-aligned values improve readability, usability, and compliance with accessibility standards.

Developer Experience Considerations

From the developer’s perspective, inconsistent values directly impact workflow efficiency, maintainability, and scalability:

Implementation Friction

Developers using frameworks like Tailwind, Chakra, or Material UI rely on token scales.
If a design specifies 13.7px spacing, there’s no matching class/token. The developer must approximate, hardcode, or create an exception → wasting time and introducing inconsistencies.

Code Bloat

Every arbitrary value creates a one-off CSS rule. Over time, this bloats the codebase and makes styles harder to manage.
Token-based systems, by contrast, enable lean, reusable CSS.

Onboarding New Developers

With inconsistent values, new team members struggle to understand what’s “standard” vs. what’s an exception.
With token-based, whole-number scales, the rules are predictable → reducing onboarding friction.

Collaboration Between Teams

Consistency reduces “pixel pushing” back-and-forth between designers and developers.
Developers can implement designs faster with fewer deviations, and QA testers spend less time verifying visual alignment.

👉 In short, inconsistency slows developers down and creates technical debt, while consistency accelerates delivery and preserves design intent.

The Power of Grid Systems

Most design systems advocate for the 4px or 8px grid system.

Keeps spacing, typography, and components consistent.
Scales well across screen sizes and densities.
Simplifies design handoff because designers and developers both speak the same scale.

Best Practices for Designers

Use design tokens only → stick to predefined scales.
Avoid fractional values → round to the nearest token value.
Export icons in whole pixel dimensions → 16px, 20px, 24px, etc.
Stick to a type scale → 12, 14, 16, 20, 24 (no decimals).
Collaborate with developers early → agree on token definitions to prevent drift.

Conclusion

Decimals and inconsistent values may seem harmless in design tools, but they cause real technical problems during implementation: blurry icons, rendering inconsistencies, bloated CSS, inaccessible touch targets, and broken design tokens.

By adhering to whole-number values aligned with design tokens and grid systems, designers and developers can ensure consistency, accessibility, scalability, and a smoother design-to-code workflow.

Design is not just about how it looks in Figma—it’s about how well it translates into code and scales across platforms. And that translation depends heavily on consistency, precision, and respect for the system.

📘 Essential Front-End Development Rules for Clean, Reusable Code

i am message — Fri, 22 Aug 2025 14:06:56 +0000

As frontend developers, one of the easiest mistakes we make early on is writing messy, inconsistent code, especially when it comes to styling. Between utility-first frameworks like Tailwind, component libraries like Ant Design, and old standbys like Bootstrap, it's easy to get carried away mixing tools or reinventing styles that already exist.

The key to writing clean, maintainable, and reusable code is discipline. Below are four fundamental rules that can help new frontend developers stay consistent and avoid common pitfalls.

Rule 1: Stick to One Library 🎯

If you've chosen a UI library, whether it's Bootstrap, Tailwind CSS, Shadcn (which builds on Tailwind), or Ant Design, commit to it.

Why This Matters:

Mixing multiple libraries creates unnecessary bloat and inconsistencies
A single library ensures your design system is predictable and your project remains easy for others to read and maintain
Most modern libraries are powerful enough to handle 90% of your use cases, so learn their feature set thoroughly before bringing in alternatives

Implementation:

Choose one styling framework as your primary solution
Resist the temptation to mix multiple frameworks unless absolutely necessary
Maintain consistency across your entire project

💡 Tip: Explore the documentation deeply. Chances are, the utility or component you're about to write already exists in your chosen library.

Rule 2: Exhaust the Utility Classes Before Writing Custom Styles 🔧

Many beginners jump straight into writing new CSS rules for simple tweaks like spacing, typography, or colors. This leads to duplicated styles and harder-to-maintain code.

Instead, trust the utility classes your library provides.

Benefits:

Rapid Development: Pre-built utilities speed up styling
Design System Consistency: Utilities enforce design constraints
Responsive Design: Most utilities include responsive variants
Reduced CSS Bloat: No duplicate or conflicting custom styles

Example:

Instead of writing:
❌ Bad:

.tiny-link { 
  font-size: 12px; 
  font-weight: bold; 
}

<a class="tiny-link">Read more</a>

✅ In Tailwind, you’d just use:

<a class="text-xs font-bold">Read more</a>

Using utilities keeps everything consistent, semantic, and maintainable.

Rule 3: Trust the Library Before Adding Custom Props or Overrides 🤝

Libraries and HTML elements already provide sensible defaults and properties. Before you override them with custom props or inline styles, see if the library can handle it first.

Key Principles:

Use library-provided components and their intended APIs
Prefer library's sizing, spacing, and layout systems
Utilize built-in responsive breakpoints and design tokens
Add custom modifications only when library solutions are insufficient

Example 1: Button Component

❌ Bad - Custom props that fight the system:

interface BadButtonProps {
  children: React.ReactNode;
  width?: number;
  height?: number;
  backgroundColor?: string;
  textColor?: string;
  borderRadius?: number;
  fontSize?: number;
  padding?: string;
  onClick?: () => void;
}

const BadButton: React.FC<BadButtonProps> = ({
  children,
  width = 120,
  height = 40,
  backgroundColor = '#3b82f6',
  textColor = '#ffffff',
  borderRadius = 8,
  fontSize = 14,
  padding = '8px 16px',
  onClick
}) => {
  return (
    <button
      onClick={onClick}
      style={{
        width: `${width}px`,
        height: `${height}px`,
        backgroundColor,
        color: textColor,
        borderRadius: `${borderRadius}px`,
        fontSize: `${fontSize}px`,
        padding,
        border: 'none',
        cursor: 'pointer'
      }}
    >
      {children}
    </button>
  );
};

// Usage creates inconsistency
<BadButton width={200} height={50} backgroundColor="#ef4444">
  Delete
</BadButton>

✅ Good - Extends HTML button with design system variants:

import { cn } from "@/lib/utils";
import { cva, type VariantProps } from "class-variance-authority";

const buttonVariants = cva(
  "inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring disabled:opacity-50 disabled:pointer-events-none",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/90",
        destructive: "bg-destructive text-destructive-foreground hover:bg-destructive/90",
        outline: "border border-input hover:bg-accent hover:text-accent-foreground",
        secondary: "bg-secondary text-secondary-foreground hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
        link: "underline-offset-4 hover:underline text-primary"
      },
      size: {
        default: "h-10 py-2 px-4",
        sm: "h-9 px-3 rounded-md",
        lg: "h-11 px-8 rounded-md",
        icon: "h-10 w-10"
      }
    },
    defaultVariants: {
      variant: "default",
      size: "default"
    }
  }
);

interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

const Button: React.FC<ButtonProps> = ({
  className,
  variant,
  size,
  ...props
}) => {
  return (
    <button
      className={cn(buttonVariants({ variant, size, className }))}
      {...props}
    />
  );
};

// Usage follows design system
<Button variant="destructive" size="lg" className="w-full">
  Delete Account
</Button>

Example 2: SVG Icon Component

❌ Bad - Custom props that bypass HTML attributes:

interface BadIconProps {
  width?: number;
  height?: number;
  color?: string;
  strokeWidth?: number;
  className?: string;
}

const BadTrashIcon: React.FC<BadIconProps> = ({
  width = 24,
  height = 24,
  color = '#000000',
  strokeWidth = 2,
  className
}) => {
  return (
    <svg
      width={width}
      height={height}
      className={className}
      viewBox="0 0 24 24"
      fill="none"
      xmlns="http://www.w3.org/2000/svg"
    >
      <path
        d="M3 6h18M19 6v14a2 2 0 01-2 2H7a2 2 0 01-2-2V6m3 0V4a2 2 0 012-2h4a2 2 0 012 2v2"
        stroke={color}
        strokeWidth={strokeWidth}
        strokeLinecap="round"
        strokeLinejoin="round"
      />
    </svg>
  );
};

// Usage creates inconsistent styling
<BadTrashIcon width={32} height={32} color="#ef4444" strokeWidth={3} />

✅ Good - Extends SVG element and uses currentColor:

import { forwardRef } from "react";

interface IconProps extends React.SVGProps<SVGSVGElement> {}

const TrashIcon = forwardRef<SVGSVGElement, IconProps>(
  ({ className, ...props }, ref) => {
    return (
      <svg
        ref={ref}
        className={className}
        viewBox="0 0 24 24"
        fill="none"
        stroke="currentColor"
        strokeWidth="2"
        strokeLinecap="round"
        strokeLinejoin="round"
        {...props}
      >
        <path d="M3 6h18M19 6v14a2 2 0 01-2 2H7a2 2 0 01-2-2V6m3 0V4a2 2 0 012-2h4a2 2 0 012 2v2" />
      </svg>
    );
  }
);

TrashIcon.displayName = "TrashIcon";

// Usage works with design system classes
<TrashIcon className="h-6 w-6 text-red-500 hover:text-red-700" />
<Button variant="destructive" className="text-white">
  <TrashIcon className="h-4 w-4 mr-2" />
  Delete
</Button>

Why These Examples Matter:

Button Component Benefits:

Uses design system variants instead of arbitrary props
Extends native HTML button attributes for accessibility
Leverages Tailwind classes for consistent sizing and spacing
Maintains type safety with proper TypeScript interfaces

SVG Icon Benefits:

Uses currentColor to inherit text color from parent
Extends all native SVG properties for maximum flexibility
Works seamlessly with utility classes for sizing and colors
Can be styled contextually by parent components

This approach ensures you're working with your design system instead of against it. Override only when it's absolutely necessary.

Rule 4: Keep Components Small and Focused 🎯

One of the best ways to keep your code reusable is to make sure your components do one thing well.

The Principle:

A component should be focused on a single responsibility, whether that's rendering a button, a card, or a form input
If a component grows too large or tries to do too much, split it into smaller subcomponents
Smaller components are easier to test, reuse, and maintain

Example:

Instead of creating a single massive UserProfile component that handles layout, fetching data, and rendering UI:

✅ Better approach:

Create smaller components like UserAvatar, UserBio, and UserStats
Compose them inside UserProfile

This makes your project easier to extend later without rewriting large chunks of code.

Why These Rules Matter 🚀

Following these rules is essentially about discipline:

Consistency: Your code looks the same no matter who writes it
Maintainability: Anyone new to the project can jump in without learning multiple systems
Reusability: Components remain generic and adaptable instead of being one-off hacks
Performance: Avoid bloated builds from multiple frameworks
Team Collaboration: Shared conventions make collaboration smoother

Related Principles 📚

These rules don't exist in isolation, they reflect established software principles:

Single Source of Truth (SSOT): One UI library as the canonical styling source
Don't Repeat Yourself (DRY): Avoid writing styles that already exist
Convention over Configuration: Follow the conventions of your chosen library
Design System Discipline: Stick to the system, extend only when needed
Single Responsibility Principle (SRP): Each component should do one thing well

Industry Standards:

Utility-First CSS - Popularized by Tailwind CSS
Atomic Design by Brad Frost - Building consistent UI components
Design Tokens - Standardized design decisions in code
Component-Driven Development - Building UIs from reusable components

Conclusion 💡

Clean frontend code isn't about avoiding creativity, it's about using the right tools the right way. By sticking to one library, fully exploring its utilities, trusting its conventions, and keeping components small and focused, you'll write code that's not only clean and reusable but also easy for your team to maintain and scale.

Remember: discipline in following these rules early on will save you countless hours of refactoring later.

What's your biggest challenge when it comes to writing clean frontend code? Share your thoughts in the comments below! 👇

Set up github work/company email on mac together with your personal github account

i am message — Wed, 09 Jul 2025 15:40:10 +0000

Here’s a clean step-by-step outline to generate and add an SSH key from your macbook to GitHub, using your company email your_personal_company_email as the identifier.

🛠️ Add SSH Key to GitHub – Step-by-Step

1. Generate the SSH Key

In terminal, run:

ssh-keygen -t rsa -b 4096 -C "your_personal_company_email"

This command generates a new SSH key pair (used to securely authenticate with services like GitHub).

Explanation of Each Part:

Part	Meaning
`ssh-keygen`	The command to generate a new SSH key.
`-t rsa`	Specifies the type of key to create. `rsa` is a widely used algorithm.
`-b 4096`	Sets the bit size of the key. `4096` bits is stronger than the default `2048`.
`-C "your_email@example.com"`	Adds a label (comment) to the key file so you can identify it later — usually your email.

When prompted:
- Enter file name: give it a custom name like your_name-company (e.g. /Users/mac/.ssh/your_name-company)
- Press Enter to skip passphrase (or set one if you prefer extra security)

2. Add the Key to SSH Agent

The SSH agent is a background program that holds your private SSH keys in memory. This means you won’t need to enter your passphrase every time you use the key (e.g., when pushing to GitHub).

First, start the SSH agent:

eval "$(ssh-agent -s)"

This command starts the SSH agent and sets up the necessary environment variables so your terminal can communicate with it.

Next, add your private key to the agent:

ssh-add ~/.ssh/your_name-company

Replace your_name-company with the actual name of your private key file (not the .pub one).

Once added, the agent will remember your key for the current session, allowing passwordless SSH/Git operations.

3. Copy the Public Key to Clipboard

Run:

pbcopy < ~/.ssh/your_name-company.pub

This copies the SSH key to your clipboard.

4. Add the Key to GitHub

Go to: https://github.com/settings/ssh/new
Title: e.g. MacBook - Company
Key: paste the copied content (Cmd+V)
Click “Add SSH Key”

5. Update `~/.ssh/config` File

Open it:

nano ~/.ssh/config

Add this block:

# GitHub for company
Host github.com-company
  HostName github.com
  User git
  IdentityFile ~/.ssh/your_name-company
  IdentitiesOnly yes

Save:

Press Ctrl + O, then Enter to save
Press Ctrl + X to exit

6. Test the Connection

Run:

ssh -T git@github.com-company

Expected:

Hi your-username! You've successfully authenticated...

7. Clone the Repo Using the Alias

Use this to clone:

git clone git@github.com-company:company/repository.git

📚 Sources

Semantic HTML Not
Soup: The Importance of Semantic HTML in Modern Web Development

i am message — Mon, 02 Jan 2023 11:50:00 +0000

What is Semantic HTML?

Semantic HTML refers to the use of HTML elements that carry inherent meaning and purpose, both for developers and for the technologies that consume web content such as browsers, search engines, and assistive tools like screen readers. Unlike non-semantic elements (e.g., <div> and <span>), semantic elements clearly describe their role in the document structure.

For example:

<header> indicates introductory content or navigation.
<footer> represents closing content or metadata for a page or section.
<article> identifies independent, self-contained pieces of content such as blog posts or news stories.
<section> groups related content under a thematic division.
<aside> signals supplementary or tangential content, such as sidebars or callouts.

By applying these elements correctly, developers create documents that are not only visually structured but also meaningfully structured.

Why Semantic HTML Matters

1. Improved Accessibility

Semantic HTML is foundational for web accessibility (a11y). Screen readers and assistive technologies rely on the semantic meaning of elements to help visually impaired users navigate a webpage. For example, a screen reader can announce when it enters an <article> or <nav>, allowing users to skip to relevant sections.

Reference: W3C Web Accessibility Initiative (WAI) emphasizes semantic HTML as a best practice for accessible design.

2. Better SEO and Search Engine Crawling

Search engines use semantic elements to interpret the hierarchy and relevance of content. For example, wrapping content in <article> or <section> provides context that can improve how search engines classify and rank the content.

In addition, semantic HTML enhances the effectiveness of structured data (Schema.org), which can lead to rich snippets in search results (e.g., article previews, FAQs, product details).

Reference: Google’s SEO Starter Guide stresses the importance of semantic markup for crawlability and ranking.

3. Maintainable and Scalable Code

Semantic HTML improves developer experience by making the codebase more readable, maintainable, and collaborative. A new developer reviewing a project will understand <header>, <main>, or <footer> far more intuitively than a sea of nested <div> elements. This reduces onboarding time and the likelihood of errors.

4. Consistency Across Devices and Tools

Browsers, search engines, and assistive technologies have built-in behaviors for semantic elements. For instance, headings (<h1> through <h6>) automatically create a document outline, while <nav> elements are identified as navigation landmarks. These consistent behaviors make web content more robust across devices and tools.

Reference: HTML Living Standard – WHATWG outlines semantic elements and their intended roles in document structure.

Practical Examples

Consider the difference between these two snippets:

Non-semantic (div soup):

<div id="header">
  <div class="title">My Blog</div>
</div>
<div class="content">
  <div class="post">Latest Post</div>
</div>

Semantic (clear meaning):

<header>
  <h1>My Blog</h1>
</header>
<main>
  <article>
    <h2>Latest Post</h2>
  </article>
</main>

The second example not only conveys structure to developers but also communicates meaning to assistive technologies and search engines.

Semantic vs. Non-Semantic Elements

Here’s a comparison of some common semantic elements and their non-semantic equivalents:

Semantic Element	Purpose	Non-Semantic Equivalent	Problem with Non-Semantic Use
`<header>`	Introduces content, page, or section header	`<div id="header">`	Loses meaning to screen readers/search engines
`<footer>`	Closing or metadata for a page/section	`<div id="footer">`	No structural significance
`<nav>`	Defines primary navigation links	`<div class="nav">`	Search engines can’t identify navigation
`<main>`	Denotes the primary content of a page	`<div id="main">`	Harder for assistive tech to find main content
`<article>`	Self-contained, reusable content (blog post, news)	`<div class="article">`	Treated as generic container
`<section>`	Groups related content under a theme	`<div class="section">`	No semantic grouping, weak document outline
`<aside>`	Tangential or secondary content (sidebars)	`<div class="sidebar">`	No distinction from main content
`<h1>`–`<h6>`	Headings that define hierarchy	`<div class="title">`	Breaks page outline, harms SEO

This table demonstrates how semantics provide machine-readable meaning, while non-semantic markup only provides styling hooks.

Best Practices for Using Semantic HTML

Use headings in order (<h1> → <h2> → <h3>): Don’t skip levels; this ensures a proper document outline.
Reserve <h1> for the main page title: Each page should typically have only one <h1>.
Use <main> only once per page: This represents the central content, not repeated sections.
Wrap navigational links in <nav>: Helps screen readers quickly locate menus.
Prefer semantic elements over <div>s and <spans>: Use <section>, <article>, <aside>, etc., wherever they apply.
Combine with ARIA roles only when necessary: Semantic HTML often eliminates the need for extra ARIA attributes.
Ensure <section> has a heading: Each <section> should start with a heading for clarity.
Avoid misuse of <section> as a generic container: Use <div> when grouping content purely for styling.
Always provide alt text for images (<img alt="...">): This complements semantic markup for accessibility.
Validate HTML regularly: Use W3C Validator to catch semantic and structural issues.

The Bigger Picture: Accessibility, SEO, and DX

Accessibility (A11y): Semantic HTML is the baseline of WCAG compliance. Without it, ARIA roles and accessibility overlays are less effective.
SEO: Semantic HTML provides the structural clarity that modern search algorithms use to evaluate content authority and relevance.
Developer Experience (DX): Code readability and collaboration are improved, reducing cognitive load for developers.

When semantic HTML is combined with CSS and JavaScript responsibly, it creates content that is meaningful, accessible, and discoverable.

Final Thoughts

Semantic HTML isn’t just about cleaner markup, it’s about building websites that are inclusive, future-proof, and search-friendly. As developers, our goal should be to ensure that both humans and machines can understand and interact with the content meaningfully.

“Use the right element for the right job.” – MDN Web Docs

By embracing semantic HTML, we’re not just writing code, we’re shaping the way people and technologies interact with the web.

DEV Community: i am message

Pixels, Tokens, and Grids: Speaking the Same Language in Design and Code

The Role of Design Tokens

Why Decimal Pixels Don’t Work

1. Rendering Inconsistency Across Devices

2. Icon Sharpness and Pixel Grid

3. Scalability and Maintainability

4. Cross-Platform Alignment

Accessibility Considerations

Developer Experience Considerations

The Power of Grid Systems

Best Practices for Designers

Conclusion

Further Reading

📘 Essential Front-End Development Rules for Clean, Reusable Code

Rule 1: Stick to One Library 🎯

Why This Matters:

Implementation:

Rule 2: Exhaust the Utility Classes Before Writing Custom Styles 🔧

Benefits:

Example:

Rule 3: Trust the Library Before Adding Custom Props or Overrides 🤝

Key Principles:

Example 1: Button Component

Example 2: SVG Icon Component

Why These Examples Matter:

Rule 4: Keep Components Small and Focused 🎯

The Principle:

Example:

Why These Rules Matter 🚀

Related Principles 📚

Industry Standards:

Conclusion 💡

Set up github work/company email on mac together with your personal github account

🛠️ Add SSH Key to GitHub – Step-by-Step

1. Generate the SSH Key

2. Add the Key to SSH Agent

3. Copy the Public Key to Clipboard

4. Add the Key to GitHub

5. Update ~/.ssh/config File

6. Test the Connection

7. Clone the Repo Using the Alias

📚 Sources

Semantic HTML Not Soup: The Importance of Semantic HTML in Modern Web Development

What is Semantic HTML?

Why Semantic HTML Matters

1. Improved Accessibility

2. Better SEO and Search Engine Crawling

3. Maintainable and Scalable Code

4. Consistency Across Devices and Tools

Practical Examples

Semantic vs. Non-Semantic Elements

Best Practices for Using Semantic HTML

The Bigger Picture: Accessibility, SEO, and DX

Final Thoughts

References

5. Update `~/.ssh/config` File

Semantic HTML Not
Soup: The Importance of Semantic HTML in Modern Web Development