Content

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

A standalone version of the readability library used for Firefox Reader View.

[…]

To parse a document, you must create a new Readability object from a document object, and then call parse(). Here’s an example:

var article = new Readability(document).parse();

This article object will contain the following properties:

• title: article title
• content: HTML string of processed article content
• length: length of an article, in characters
• excerpt: article description, or short excerpt from the content
• byline: author metadata
• dir: content direction

If you’re using Readability on the web, you will likely be able to use a document reference from elsewhere (e.g. fetched via XMLHttpRequest, in a same-origin <iframe> you have access to, etc.).

Carousels (or ‘content sliders’) are like men. They are not literally all bad — some are even helpful and considerate. But I don’t trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don’t have the choice. Hence this article.

Carousels don’t have to be bad, but we have a culture of making them bad. It is usually the features of carousels, rather than the underlying concept that is at fault. As with many things inclusive, the right solution is often not what you do but what you don’t do in the composition of the component.

[…]

• Use list markup to group the slides together. Then screen reader users in ‘browse’ mode can use list navigation shortcuts to traverse them.
• Provide a reasonable experience in HTML with CSS, then feature detect when enhancing with JavaScript.
• Don’t preload content users are not likely to see. Defer until they perform an action to see it.
• Provide generous touch targets for touch users on mobile / small screens.
• If in doubt of a control’s (or widget’s) affordance, spell it out with instructions
• If you are a man and got past the first paragraph without being personally offended: Congratulations! You do not see men and women as competing teams.

This asks the question ‘Is this element the first-child and the fourth-last element that I’m working on OR does this element come after the first-child and the fourth-last element that I’m working on?’