Skip to main content


MWF includes a foundational framework consisting of layers including structure (HTML), styles (CSS), and behaviors (JavaScript) architected as a loosely coupled stack providing for a scalable, performant, and maintainable fluent design system.

MWF progressively enhances user experiences from old browsers, text-only browsers, to modern browsers with high fidelity and interaction. This approach helps enforce and deliver semantically meaningful HTML for all users.

A layered approach to the technology stack provides flexibility to change or upgrade different layers without impact to other layers. For example, the system allows page authors to choose a different grid.

Components include microdata when appropriate as part of the HTML structure to make them machine readable by search engines and web crawlers.

Components include finely tuned accessibility properties for users with cognitive, visual, audible and physical impairments or disabilities.

Building blocks

MWF has many building blocks distinguished as "components" or "modules." Components are our smallest building blocks, while modules are larger, more complex, and are frequently built using one or more components.

All building blocks have default CSS styles and some include unique behaviors enabled through our JavaScript Library. The style and behavior are applied regardless of where on the page the object is located.

Building blocks can also be altered with styles or behaviors scoped to contexts. A context is a contextual shift in the design which require progressive style and/or behavior change for one or more of the building blocks it contains and usually seen in modules.

Semantic objects

The Microsoft Web Framework provides a large library of modules and components representing semantic objects such as button, hero, or heading. Each addressing a specific use case or scenario. We avoid adding more than one object for the same scenario.

Every object should always have a default style and behavior that is applied no matter where on the page it's used. The default can be overridden when necessary using contexts or a parent component acting as a context.

Structured markup

The HTML part of any object should be as simple, consistent, and based on the content, not the style. The HTML is documented as a reference. To use a component, simply use the example HTML in your Web page. Even though modifications to objects HTML may be possible without breaking the style, doing so may cause unexpected effects in the long run.

Scripting behaviors

MWF includes an object based JavaScript Library to add functional behavior and interactive animations. MWF defines each object it it's library. And, of course, you can define your own objects. Whenever JavaScript is required it should be injected by JavaScript so that non JavaScript browsers aren't polluted with unnecessary markup.

To interact with these objects from JavaScript requires that the object is initialized. Some controls can be initialized automatically on loading and some require manual initialization using a component factory pattern. Most modules (and some components) provide event notification using a pub/sub scheme. Thus, your code can subscribe to a module's unique event notification and react accordingly. These events are usually more complex than the simple events available from HTML elements, reflecting the rich functional context of the module.

Styling objects

Building blocks are styled with class names denoted by "c-". For example, c-component-name. Component functions are denoted by "f-" which can impact the style related to the assigned functionality. For example, f-option-name.

Name standards

Strict naming standards are required and when used appropriately will help improve quality and readability for learning and using MWF.

  • Markup naming conventions including resource file names (attributes, etc) shall be lower case, hyphen-delimited and no abbreviations except for industry known acronyms.
  • Markup id names shall be camelCased (e.g.: shopNow) and/or Hungarian notation (e.g.: frmShop).
  • Element attributes are purposeful and follow this specific order. id -> structure -> styles -> behavior -> accessibility -> micro-data -> misc attributes. For example, <div id="fooStuff" data-grid="col-12 pad-3x" class="m-hero context-app f-x-left" role="region" aria-label="Just more descriptive text for screen readers" item-prop="priceCurrency" content="USD" data-awa="stuff">. Note this is not a real code example just an example if an HTML element used all the attributes possible.

Class names

Semantic objects use custom named class selectors to improve maintainability and separation of concerns. Always include the proper scoping when building pages.

Name Code Summary
Partner ***

Partner selectors are defined by a three letter abbreviation representing their domain property. Of course, this is optional, though helpful when requesting support by MWF team as it aids in maintainability of MWF.

For example: Microsoft Design Language may use mdl- for custom components they deem appropriate based on their requirements. This should be used consistently in tandem with additional codes.

Partner selectors for context, modules, and components

Context context-

Context selectors represent a shift in behavior, style, and position within a page.

For example: Sample pages may require vertical spacing between paragraphs.
.context-sample-page .c-paragraph { margin-top: 24px; }

Module m-

Module selectors define a reusable group of components. The class gets applied to root element of each module.

For example: Sample pages may require vertical spacing between paragraphs.
.m-* .c-paragraph { margin-top: 24px; }

Component c-

Component selectors are used for default behavior (JavaScript, optional) and style (CSS) of a component.

For example:

Function f-

Function selectors are used for changes in style (CSS) and behavior (JavaScript) for components.

Function selectors are always used in conjunction with a component, never on their own. A CSS rule would never be tied directly to the function selector, instead it would be tied to a component.

For example:

.c-button.f-toggle {}

.f-toggle {}

Theme theme-

Theme selectors define component style inside a content area.

For example: To change the style of components to display properly on a dark colored background.

Image names

In staging and production environments file naming can come in a variety of implementations. Ideally we should enforce consistency across all the different possibilities for managing images. MWF follows the same consistent practices in development.

  • Hyphen delimit each word in the file name.
  • If one image size for all viewports, then *-vp-* is not necessary.
  • Last word in the name refers to the viewport the image is used at. (*-vp1, *-vp2, *-vp3, *-vp4, *-vp5, *-vp6)