May 2025 – My Point of View

Front-End Development Trends

When HTML was first created, it was used to present some basic formatting. You could bold certain text, you could underline certain text, etc. Later, this activity became interactive with forms. Over time, these forms became more complicated and AJAX-based tools really unleashed the possibility of what could be possible in a browser. Then, paired with the additional complexity of security and the fact that accessibility has become extremely important and essential, our plain old HTML friend started clearly showing its age. As a result, HTML had to evolve.

These days, the vast majority of new applications are served through the browser. In fact, sit back and think about it: How many new products that have been launched in the last 10 years that you use on your laptop or desktop are not web applications?

Most of these websites have some common features. They all seem to have a header, paragraphs, navigation footers, etc. For the longest time, we’ve been trying to twist tags, like div and span, with some clever CSS to act like a header, paragraphs, navigation footers, etc. Semantic HTML changes that.

Semantic HTML is a way of writing HTML that focuses on the meaning of the content rather than just its presentation. It involves using HTML elements that describe the structure and purpose of the content, making it more readable, accessible, and maintainable. Semantic HTML uses elements that provide meaning to the structure of the web page.

Semantic HTML is a standard, as defined by the World Wide Web Consortium (W3C) and maintained by the WHATWG (Web Hypertext Application Technology Working Group). The HTML specification, which includes the definition of semantic HTML elements, is a standard document that outlines the syntax, structure, and semantics of HTML. This specification is maintained by the WHATWG and is widely adopted by web browsers and other HTML parsers.

The use of semantic HTML elements, such as <header>, <nav>, <main>, <section>, <article>, <aside>, <footer>, and others, is mandated by the HTML specification. These elements provide a standardized way to define the structure and meaning of web content, making it easier for browsers, search engines, and other tools to understand and interpret the content.

Although there may be some flexibility in how semantic HTML elements are used, the specification provides clear guidelines on their usage and meaning.

Semantic HTML in practice means that instead of writing…. this article is continued online. Click here to continue.

Conditional Nested Validation with FluentValidation

This example demonstrating how to conditionally validate nested objects using FluentValidation’s When method.

Scenario

Let’s say we have:

A Person class with an Address property
We only want to validate the Address when HasAddress is true

Model Classes

public class Person
{
    public string Name { get; set; }
    public bool HasAddress { get; set; }
    public Address Address { get; set; }
}

public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public string ZipCode { get; set; }
}

Validator Implementation

public class PersonValidator : AbstractValidator<Person>
{
    public PersonValidator()
    {
        // Always validate name
        RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
        
        // Only validate address when HasAddress is true
        When(x => x.HasAddress, () => 
        {
            RuleFor(x => x.Address)
                .NotNull()
                .WithMessage("Address must be provided when HasAddress is true");
                
            RuleFor(x => x.Address.Street)
                .NotEmpty()
                .When(x => x.Address != null)
                .WithMessage("Street is required");
                
            RuleFor(x => x.Address.City)
                .NotEmpty()
                .When(x => x.Address != null)
                .MaximumLength(50);
                
            RuleFor(x => x.Address.ZipCode)
                .NotEmpty()
                .When(x => x.Address != null)
                .Matches(@"^\d{5}(-\d{4})?$");
        });
    }
}

Alternative Approach (Using Child Validator)

public class PersonValidator : AbstractValidator<Person>
{
    public PersonValidator()
    {
        RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
        
        When(x => x.HasAddress, () => 
        {
            RuleFor(x => x.Address)
                .NotNull()
                .SetValidator(new AddressValidator());
        });
    }
}

public class AddressValidator : AbstractValidator<Address>
{
    public AddressValidator()
    {
        RuleFor(x => x.Street).NotEmpty();
        RuleFor(x => x.City).NotEmpty().MaximumLength(50);
        RuleFor(x => x.ZipCode).NotEmpty().Matches(@"^\d{5}(-\d{4})?$");
    }
}

Usage Example

var person = new Person 
{
    Name = "Khan",
    HasAddress = false,
    Address = null
};

var validator = new PersonValidator();
var result = validator.Validate(person); // Won't validate address

Key Points:

The When condition determines whether the nested rules should execute
The nested rules are only evaluated if HasAddress is true
We still need null checks for the address object itself
The second approach using a separate validator is cleaner for complex nested objects

This pattern is useful when you want to validate complex objects only in certain scenarios, reducing unnecessary validation overhead.