7. Web Platform Foundations for Interface Development

Introduction and Context

A web interface is not merely a visual arrangement of colours, images, and controls. It is an executable document interpreted by browsers, assistive technologies, search engines, development tools, and increasingly automated agents. The quality of an interface therefore depends on more than appearance. It must express meaning through HTML, establish presentation through CSS, respond to interaction through JavaScript, and remain usable across devices, browsers, input methods, network conditions, and user abilities.

For a full stack developer, these technologies form the client-side foundation on which frameworks and design systems are built. React, Vue, Angular, utility CSS libraries, testing platforms, and build tools do not replace the web platform. They organise or extend it. A developer who understands the platform can select abstractions intelligently, diagnose failures, produce accessible interfaces, and avoid unnecessary complexity.

This chapter examines the relationship between semantic HTML, modern CSS, JavaScript, the Document Object Model (DOM), events, browser rendering, progressive enhancement, component architecture, version control, and development tooling. The emphasis is not on memorising syntax but on understanding how decisions made during interface development affect maintainability, performance, accessibility, and professional delivery.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the roles and relationships of HTML, CSS, and JavaScript in a web interface.

2. Select semantic HTML elements and construct accessible document structures.

3. Describe the DOM, event propagation, and the main stages of browser rendering.

4. Apply modern CSS techniques for responsive and maintainable layouts.

5. Use progressive enhancement to provide a reliable baseline experience.

6. Explain component architecture and distinguish useful abstraction from unnecessary fragmentation.

7. Organise interface work with Git and appropriate development tools.

8. Evaluate common implementation choices in terms of performance, accessibility, security, and maintainability.

The Web Platform as an Interface System

A browser receives resources, usually beginning with an HTML document, and constructs an interactive representation of the page. HTML supplies structure and meaning. CSS supplies visual rules and layout behaviour. JavaScript supplies computation and dynamic interaction. These roles overlap in practice, but separating them conceptually is valuable.

HTML should answer the question, “What is this?” A heading is a heading, a navigation region is navigation, and a button is an action control. CSS answers, “How should it be presented under these conditions?” JavaScript answers, “How should the interface respond when its state or the user’s actions change?” When these responsibilities are mixed carelessly, systems become difficult to test and inaccessible. For example, styling a generic `div` to look like a button does not automatically provide keyboard interaction, focus behaviour, or the semantics expected by assistive technologies.

The platform is also governed by standards and interoperable browser behaviour. Standards compliance does not mean that every browser behaves identically in every detail. It means that developers use defined platform features, test significant variations, and avoid relying on accidental behaviour. Progressive enhancement and feature detection are practical responses to this diversity.

Important terminology

The user agent is the software that retrieves and presents web content, usually a browser. The viewport is the visible area in which a page is rendered. A resource is an asset such as an HTML document, stylesheet, script, font, or image. Semantics refers to the meaning communicated by structure and elements rather than their visual appearance. State is information describing the current condition of an interface, such as whether a menu is open or a form is being submitted.

Semantic HTML: Structure Before Decoration

Semantic HTML uses elements according to their intended meaning. A document may contain `header`, `nav`, `main`, `section`, `article`, `aside`, and `footer`, but these elements are not simply styling containers. They help browsers, search engines, screen readers, and developers interpret the information architecture.

A well-formed page normally has a logical heading hierarchy, a clearly identifiable main content region, meaningful link text, labels associated with form controls, and lists represented with list elements. A link moves the user to a resource or location; a button performs an action. Maintaining this distinction improves keyboard behaviour, accessibility, and user expectations.

Consider the following structure:

```html

<header>

<a href="/" aria-label="Acme home">Acme</a>

<nav aria-label="Primary navigation">

<ul>

<li><a href="/products">Products</a></li>

<li><a href="/support">Support</a></li>

</ul>

</nav>

</header>

<main>

<h1>Product catalogue</h1>

<section aria-labelledby="featured-heading">

<h2 id="featured-heading">Featured products</h2>

<!-- product content -->

</section>

</main>

<footer>...</footer>

```

The elements communicate relationships without requiring a visual inspection. A heading should not be selected merely because it looks large; visual appearance belongs in CSS. Likewise, a section should normally have a heading when it represents a thematic grouping. The correct element reduces the amount of ARIA required. ARIA should supplement native semantics, not replace them when an appropriate HTML element exists.

Forms illustrate the importance of semantic structure. A label should be programmatically connected to its control, error messages should identify the relevant field, and the form should expose a meaningful submission action. Native constraints such as `required`, `type="email"`, and `minlength` can provide useful baseline validation, although server-side validation remains essential because client-side controls can be bypassed.

Images require decisions about purpose. Informative images need concise alternative text; decorative images should generally have empty alternative text so they are not announced unnecessarily. A complex image may require a longer textual explanation. Accessibility is therefore an information-design issue, not simply a compliance checklist.

CSS as a System of Constraints

CSS is often introduced as a set of visual properties, but modern CSS is better understood as a rule system that resolves competing constraints. The cascade determines which declarations apply. Specificity, source order, inheritance, layers, and importance all influence the result. The box model determines how width, padding, borders, and margins contribute to layout. The formatting context determines how elements participate in flow, flex layout, grid layout, or positioning.

A maintainable stylesheet establishes predictable foundations. A common baseline is:

```css

, ::before, *::after {

box-sizing: border-box;

}

:root {

--color-text: #17202a;

--color-surface: #ffffff;

--space-unit: 0.25rem;

}

body {

margin: 0;

color: var(--color-text);

background: var(--color-surface);

font-family: system-ui, sans-serif;

line-height: 1.5;

}

```

Custom properties allow design decisions to be expressed as reusable tokens. They can represent colour, spacing, typography, radii, and motion preferences. However, tokens should reflect a coherent design system rather than become a large collection of arbitrary values.

Flexbox is suited to one-dimensional arrangements, such as a row of navigation items or the alignment of controls within a toolbar. Grid is suited to two-dimensional relationships, such as a product catalogue with explicit columns and rows. Neither should be selected because it is fashionable; the choice should follow the structure of the problem. Absolute positioning is useful for overlays and precisely anchored decorative elements, but it is a poor general strategy for page layout because content size and viewport dimensions vary.

Responsive design is not simply the creation of separate desktop and mobile pages. It is the design of a flexible system that adapts to available space, input conditions, content length, and user preferences. Relative units, flexible tracks, `minmax()`, `clamp()`, responsive images, and content-based breakpoints support this goal. A breakpoint should be introduced when the content or interaction becomes unsuitable, not because a particular device model has been named.

For example:

```css

.product-grid {

display: grid;

grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));

gap: 1rem;

}

.page-title {

font-size: clamp(1.75rem, 1.2rem + 2vw, 3rem);

}

```

This layout can create as many columns as the available width supports while preventing cards from becoming unusably narrow. Responsive CSS should also account for reduced motion, increased text size, high contrast needs, and touch targets. Media queries such as `prefers-reduced-motion` express user preferences, but they do not replace good interaction design.

JavaScript, the DOM, and Interface State

JavaScript does not directly manipulate “the page” in an abstract sense. It executes against objects exposed by the browser, including the document, elements, event targets, storage mechanisms, network APIs, and timing facilities. The DOM is a tree-like object representation of the document. It is related to, but not identical with, the original HTML source.

A script can query an element, modify its attributes or text, insert nodes, and change classes. For example:

```js

const toggle = document.querySelector('[data-menu-toggle]');

const menu = document.querySelector('#primary-menu');

toggle.addEventListener('click', () => {

const isOpen = menu.classList.toggle('is-open');

toggle.setAttribute('aria-expanded', String(isOpen));

});

```

The important principle is that visual state and communicated state must remain consistent. If a menu is open visually but `aria-expanded` still reports `false`, users receive contradictory information. State should have a clear owner, transitions should be predictable, and DOM updates should be limited to what is necessary.

Modern JavaScript development also involves modules, asynchronous operations, promises, and the `fetch` API. Network requests may fail, take longer than expected, or return invalid data. A professional interface represents loading, success, empty, and failure states rather than assuming that a request always succeeds. User-facing error messages should be understandable, while detailed technical information belongs in diagnostic logs rather than exposed indiscriminately.

Events and Interaction Architecture

An event represents something that occurs in the browser environment, such as a click, key press, input change, focus transition, submission, or pointer movement. Event listeners connect these occurrences to application behaviour.

Events move through phases commonly described as capturing, target, and bubbling. During capturing, an event travels toward its target. It reaches the target and may then bubble outward through ancestor elements. Event delegation uses bubbling to place one listener on a stable ancestor and determine which descendant initiated the event. This is particularly useful for lists whose items are created dynamically.

```js

const list = document.querySelector('.results');

list.addEventListener('click', (event) => {

const button = event.target.closest('[data-remove]');

if (!button || !list.contains(button)) return;

removeResult(button.dataset.remove);

});

```

Developers must distinguish event types carefully. `click` is often appropriate for buttons and links, while `input` is useful when a value changes during typing and `submit` is appropriate for form submission. Keyboard-specific handlers should be used only when native controls cannot provide the required behaviour. Preventing default browser behaviour without a clear reason can break navigation, form submission, keyboard access, or assistive technology interaction.

Focus management deserves special attention. A keyboard user should always have a visible focus indicator and a logical focus order. Dialogs, menus, and dynamically inserted content may require deliberate focus movement. A component that opens a modal but leaves focus behind it creates an interaction trap or an ambiguous experience. Correct keyboard behaviour is part of component design, not a later enhancement.

How the Browser Turns Code into Pixels

Understanding rendering helps developers make informed performance decisions. After receiving HTML, the browser parses it into a DOM. CSS is parsed into rules that contribute to a CSS object model. The browser combines these structures to determine styles, constructs a render representation for visible content, calculates geometry during layout, and paints pixels. Compositing may then combine layers for display.

The exact implementation differs among browsers, but the general sequence is useful. Changes that affect geometry, such as width or position, may trigger layout. Changes that affect visual appearance may trigger painting. Some properties can be handled efficiently by compositing, although no property should be treated as universally cost-free. Large DOM trees, forced synchronous layout, expensive selectors, oversized images, and excessive JavaScript execution can all reduce responsiveness.

Performance is a user-experience quality. A page may be technically functional but practically unsuccessful if content appears late, interaction is delayed, or layout shifts unexpectedly. Developers should measure rather than rely on intuition. Browser performance panels, network inspection, accessibility audits, and real-device testing reveal different classes of problems.

Useful strategies include loading only necessary code, deferring non-critical scripts, compressing and appropriately sizing images, reserving space for media, avoiding unnecessary DOM updates, and reducing third-party dependencies. Performance budgets can translate general aspirations into reviewable limits, but they should be interpreted in relation to the audience, device conditions, and business purpose.

Progressive Enhancement and Resilient Delivery

Progressive enhancement begins with a functional baseline and adds capabilities when the platform supports them. In a content-oriented page, the baseline may be server-rendered semantic HTML and ordinary links. CSS improves readability and layout. JavaScript then adds filtering, live updates, animation, or richer navigation.

This approach should not be confused with making every advanced application work without JavaScript. Some products genuinely require substantial client-side execution. The principle remains valuable: essential content and actions should not depend unnecessarily on fragile enhancements, and failure of one layer should not destroy the whole experience.

A related strategy is feature detection. Instead of detecting a browser name, code tests whether a capability exists. CSS uses feature queries such as `@supports`; JavaScript can test APIs before using them. A browser-specific assumption becomes brittle as devices and browser versions change. Progressive enhancement also supports accessibility, lower-powered devices, unstable networks, and maintainability.

Component Architecture: Reuse with Boundaries

A component is a coherent unit of interface structure, styling, behaviour, and sometimes data handling. Components may be implemented as framework components, web components, server-rendered partials, or informal modules. The architectural question is not whether every element should become a component. It is where a stable responsibility and boundary exist.

A useful component has a clear purpose, an understandable interface, controlled state, and predictable rendering. A button component may accept a label, type, disabled state, and event callback. A data table may own sorting state but should not silently manage unrelated application navigation. Components should expose meaningful events or callbacks rather than requiring consumers to manipulate internal DOM details.

Good boundaries often follow repeated visual patterns, interaction units, or domain responsibilities. Poor boundaries may produce “components” so small that understanding a page requires navigating dozens of files. Another danger is the monolithic component that owns data fetching, layout, validation, analytics, and unrelated business rules. Composition is usually preferable to inheritance for interface structures: combine smaller, focused units rather than building deep hierarchies with hidden behaviour.

State architecture is especially important. Local state belongs close to the component that owns it; shared state should be centralised only when multiple parts of the application genuinely depend on it. Duplicated state creates synchronisation problems. Derived values should generally be calculated from a source of truth rather than stored independently.

Version Control and Development Tooling

Interface development is collaborative engineering. Version control provides a record of change, supports experimentation, enables review, and makes recovery possible. Git repositories should contain meaningful commits, a documented setup process, and a branch or integration strategy appropriate to the team. A commit should ideally represent a coherent change rather than a mixture of unrelated formatting, refactoring, and feature work.

A professional workflow commonly includes:

• a local development server with fast feedback;
• formatting and linting rules applied consistently;
• automated tests for important behaviour;
• accessibility and performance audits;
• source maps and browser debugging for diagnosis;
• code review before integration; and
• continuous integration that validates builds and tests.

Formatting tools address consistent presentation; linters identify suspicious or error-prone code; type systems can reveal mismatched assumptions; bundlers transform and optimise modules; and package managers record dependencies. These tools reduce avoidable variation, but automation does not replace judgement. A linter cannot decide whether a heading hierarchy reflects the information architecture, and a passing build does not prove that a keyboard user can complete a task.

Dependency governance is also significant. Teams should track versions, review licences, remove unused packages, and monitor security advisories. A small package may introduce transitive dependencies or maintenance obligations disproportionate to its benefit. Build output should be inspected, especially when a development dependency accidentally enters production code.

An Applied Case: Rebuilding a Public Benefits Portal

Background

The following is an illustrative case. A regional public benefits agency has an online application portal. Its existing interface uses visually styled `div` elements, a large client-side bundle, fixed-width forms, and error messages that appear only after submission. Users report difficulty on mobile devices and frequent abandonment.

Situation and analysis

An audit identifies several related problems. The page lacks a reliable heading hierarchy and form labels are not programmatically associated with inputs. The navigation is inaccessible by keyboard. On small screens, horizontal scrolling hides required fields. JavaScript assumes successful network responses, while the server rejects incomplete or malformed submissions. The application also loads several megabytes of scripts before displaying the first form.

The problems are not isolated defects. They arise from an architecture that treats the interface as a visual application rather than as a standards-based document enhanced by software. The team therefore establishes success criteria: a user must be able to understand the form structure, complete essential fields with keyboard or touch input, recover from validation errors, and receive useful content under slow network conditions.

Approach

The team first redesigns the document structure using semantic headings, fieldsets, legends, labels, native controls, and an explicit main region. Server-side rendering provides the initial form and preserves entered values after a validation failure. CSS introduces a fluid single-column layout that expands into grouped columns only when the content permits it. It uses grid for relationships among fields and avoids fixed heights that would clip enlarged text.

JavaScript is then added selectively. It enhances address lookup, displays inline feedback while retaining server validation, and manages a progressively enhanced disclosure panel. The menu uses a native button, updates `aria-expanded`, and moves focus deliberately when a modal confirmation dialog is opened. Network requests expose loading and failure states rather than leaving the user with an inactive control.

The repository is reorganised into semantic page templates, reusable form-field components, a small validation module, and shared design tokens. Automated checks include HTML validation, linting, keyboard walkthroughs, accessibility testing, and tests for unsuccessful network responses. Git commits separate structural, styling, and behavioural changes so that reviewers can evaluate each concern.

Outcome

The redesigned portal has a usable server-rendered baseline, adapts to narrow screens, communicates errors more clearly, and sends less initial JavaScript. The team also gains a repeatable component and review process. The important outcome is not a particular framework or visual style. It is the alignment of semantics, layout, behaviour, delivery, and governance around the user’s task.

Learning points

1. Accessibility defects often indicate deeper structural problems.

2. Progressive enhancement can improve reliability without preventing rich interaction.

3. Responsive behaviour should follow content and task requirements.

4. Component reuse is most effective when responsibilities are explicit.

5. Performance and maintainability improve when unnecessary client-side work is removed.

Challenges, Risks, and Professional Judgement

One common mistake is choosing elements by appearance. A heading selected because it is large, or a button represented by a link because it is easy to style, creates semantic and behavioural debt. Another is treating accessibility as an audit performed at the end. Automated tools detect only a subset of issues; manual keyboard testing, screen-reader checks, zoom testing, and user research remain necessary.

CSS can become fragile through uncontrolled specificity, duplicated rules, and unexplained overrides. JavaScript can become fragile through global selectors, hidden state, race conditions, and event handlers that assume a particular DOM structure. Components can become fragile through excessive coupling and undocumented contracts. Version control can become ineffective when commits are opaque or dependencies are updated without testing.

Security is part of interface development. User input must be treated as untrusted data. Applications should reduce cross-site scripting risk through safe DOM APIs and appropriate output encoding, protect authenticated operations against relevant request-forgery threats, avoid exposing secrets in client-side code, and use secure transport. Content Security Policy and dependency scanning may support a broader security programme, but they do not replace secure design and server-side controls.

Privacy also influences interface choices. Analytics, personalisation, storage, and third-party scripts should have a legitimate purpose, transparent disclosure, appropriate consent where required, and data minimisation. A developer should not collect interaction data merely because a tool makes collection easy.

Emerging Directions

The platform continues to develop through capabilities such as container queries, modern responsive image behaviour, view transitions, web components, improved form controls, and more capable browser APIs. These features can reduce custom JavaScript and enable interfaces that respond to their actual containing context rather than only to the viewport.

AI-assisted coding and automated interface generation are increasingly used for scaffolding, code explanation, testing suggestions, and content transformation. They can accelerate routine work, but generated code still requires review for semantics, accessibility, security, licensing, performance, and factual correctness. Automation is most valuable when paired with explicit standards and human evaluation.

The growing importance of privacy-preserving APIs, offline-capable applications, design tokens, and component documentation also reinforces a central principle: robust interface development depends on platform knowledge. Frameworks and tools will change, but the browser’s fundamental responsibilities—interpreting structure, applying styles, handling events, and rendering content—remain essential knowledge.

Best Practices for Platform-Based Interface Development

A disciplined developer typically:

• starts with content structure and user tasks before styling;
• uses native HTML controls whenever they provide the required behaviour;
• treats keyboard access, focus, labels, contrast, and alternative text as design requirements;
• builds responsive layouts from flexible constraints rather than device assumptions;
• keeps state explicit and synchronised with communicated interface state;
• measures performance on representative devices and networks;
• enhances a reliable baseline instead of creating unnecessary dependence on JavaScript;
• defines component boundaries around responsibility and reuse;
• validates changes through linting, testing, auditing, and code review; and
• evaluates privacy, security, maintainability, and user impact alongside visual quality.

Chapter Summary

Web interfaces are standards-based systems in which semantic HTML provides meaning, CSS resolves presentation and responsive constraints, and JavaScript manages dynamic behaviour and state. The DOM represents the document as objects, while events provide the mechanism through which user actions and browser changes reach application logic. Browser rendering involves parsing, style calculation, layout, painting, and compositing; understanding these stages supports better performance decisions.

Progressive enhancement establishes a dependable baseline before adding richer capabilities. Component architecture helps organise repeated structure and behaviour, but useful components require clear boundaries and controlled state. Git, testing, linting, auditing, and build tools support professional collaboration, although tools cannot replace accessibility review or engineering judgement. Across all these concerns, semantic structure, resilience, performance, security, privacy, and maintainability should be treated as interconnected qualities rather than separate tasks.

Key Terms

Semantic HTML: HTML structure that communicates the meaning and role of content.

DOM: The browser’s object representation of an HTML document.

CSS cascade: The process by which applicable style declarations are combined and prioritised.

Specificity: The precedence value used when CSS selectors compete to style an element.

Custom property: A CSS variable defined by the author and reusable across declarations.

Responsive design: An approach in which an interface adapts to viewport, content, and user conditions.

Flexbox: A CSS layout model for arranging items primarily along one dimension.

CSS Grid: A layout model for controlling relationships across rows and columns.

Viewport: The visible area through which a user views a web document.

Event propagation: The movement of an event through capturing, target, and bubbling phases.

Event delegation: Handling events on an ancestor on behalf of suitable descendants.

State: Data representing the current condition of an interface or application.

Progressive enhancement: Building a functional baseline and adding capabilities when supported.

Feature detection: Testing for a capability rather than identifying a particular browser.

Component: A bounded, reusable unit of interface structure, style, and behaviour.

Accessibility: The design and implementation of technology usable by people with varied abilities.

Layout shift: An unexpected movement of visible content during loading or interaction.

Version control: A system for recording, reviewing, and managing changes to project files.

Linting: Automated analysis that identifies style, quality, or potential code problems.

Design token: A named, reusable value representing a design decision such as colour or spacing.

Review Questions

Short Answer Questions

1. Why should a button generally be represented by a `button` element rather than a styled `div`?

2. What is the relationship between the DOM and the original HTML source?

3. Distinguish between Flexbox and CSS Grid in terms of typical layout use.

4. What is progressive enhancement?

5. Why should client-side validation not replace server-side validation?

Long Answer Questions

1. Explain how semantic HTML contributes to accessibility, maintainability, and search interpretation.

2. Describe the principal stages through which a browser converts web resources into displayed pixels.

3. Discuss the role of state and events in the design of an interactive component.

4. Explain how responsive CSS can be designed around content rather than named devices.

5. Evaluate the contribution and limitations of Git, linting, testing, and browser development tools in a professional workflow.

Analytical / Application Questions

1. A team has created a modal dialog that opens visually when a generic element is clicked, but keyboard users cannot reach it and screen readers are not informed. Analyse the causes and propose a standards-based solution.

2. A product catalogue loads slowly because every filter and chart is included in the initial JavaScript bundle. Design a progressive enhancement and performance strategy for improving the experience.

3. A responsive form works on a large monitor but clips labels and requires horizontal scrolling when text is enlarged. Identify the likely design failures and recommend CSS, HTML, and testing changes.

22. Multiple Choice Questions with Answers

Question 1

A developer needs an element that submits a form and remains keyboard accessible without custom keyboard handlers. Which choice is most appropriate?

A. A styled div with a click listener

B. A button element with an appropriate type

C. A span containing the word Submit

D. An image with an alternative text value of Submit

Correct Answer: B. A button element with an appropriate type

Question 2

Which situation best illustrates progressive enhancement?

A. Disabling all JavaScript so every page is identical

B. Serving only a client-rendered application shell

C. Providing usable semantic HTML first, then adding richer filtering with JavaScript

D. Designing separate markup for every named mobile device

Correct Answer: C. Providing usable semantic HTML first, then adding richer filtering with JavaScript

Question 3

Why is event delegation useful for a dynamically changing list?

A. It prevents all events from bubbling

B. It allows one ancestor listener to handle suitable descendant events

C. It automatically validates every form field

D. It eliminates the need for event targets

Correct Answer: B. It allows one ancestor listener to handle suitable descendant events

Question 4

Which CSS technique most directly supports a product grid that adapts to available width without naming specific devices?

A. Fixed pixel widths for every card

B. Absolute positioning for every item

C. A grid using flexible tracks and minmax()

D. A separate stylesheet for each phone model

Correct Answer: C. A grid using flexible tracks and minmax()

Question 5

A menu is visually open, but its button still exposes aria-expanded="false". What is the principal problem?

A. The CSS cascade is disabled

B. The DOM cannot contain a navigation element

C. The communicated state conflicts with the visual state

D. The menu must use a table element

Correct Answer: C. The communicated state conflicts with the visual state

Question 6

Which change is most likely to cause layout work during browser rendering?

A. Changing an element’s width

B. Changing only the text of a console log

C. Renaming a Git branch

D. Opening the browser’s source panel

Correct Answer: A. Changing an element’s width

Question 7

Which component design decision most strongly supports maintainability?

A. Allowing every consumer to alter internal DOM nodes directly

B. Giving the component a clear responsibility and predictable interface

C. Putting all application behaviour into one large component

D. Duplicating state in every component that displays it

Correct Answer: B. Giving the component a clear responsibility and predictable interface

Question 8

Why is feature detection generally preferable to browser-name detection?

A. It guarantees that unsupported features will work

B. It tests whether the required capability is available

C. It prevents CSS from being downloaded

D. It removes the need for accessibility testing

Correct Answer: B. It tests whether the required capability is available

Question 9

Which practice is most appropriate for reducing initial interface cost?

A. Loading every dependency before displaying content

B. Using oversized images to avoid future requests

C. Deferring non-critical scripts and appropriately sizing images

D. Replacing all native controls with custom widgets

Correct Answer: C. Deferring non-critical scripts and appropriately sizing images

Question 10

In the illustrative benefits-portal case, why was server-rendered HTML retained?

A. It prevents all responsive styling

B. It provides a reliable baseline and supports failure recovery

C. It makes JavaScript event handling impossible

D. It removes the need for server-side validation

Correct Answer: B. It provides a reliable baseline and supports failure recovery