DEV Community

Kevin Cox
Kevin Cox

Posted on • Originally published at kevincox.ca on

Proposal for Chrome and Content Modes in HTML

I’ve talked before about respecting your user’s preferences in your web design. I think that this site does a good job at taking the viewer’s preferences into account, but it is far from perfect. The main problem is that there are infinite preferences a user may have, but the CSS spec can only convey hand-picked features to a site’s stylesheet.

I think that the web could provide a better reading experince with separate “Chrome” and “Content” modes that allow a site to be viewed based on the user’s preferences.

Existing Mechanisms

Browser Stylesheets

There is actually one existing mechanism that does convey enough information, the browser’s default stylesheet. These are the rules that the browser uses if you don’t provide any of your own. For example motherfuckingwebsite.com relies solely on the browser’s built in stylesheets.

However, as explained so well by bettermotherfuckingwebsite.com, it isn’t particularly easy on the eyes. Why is that? Why can’t browsers ship pretty default stylesheets? The answer is quite simple, there is no way to opt out. If a browser shipped a stylesheet that used a black background sites would break. Thousands of sites that set color: #333 for a dark grey text colour without changing the background colour would now have illegible dark grey text on a black background. The problem with the default stylesheet is that the design of sites depend on it. Anything more than minor tweaks will break layouts and styles across the web. This requirement to avoid breaking sites hamstrings the power of the default stylesheet, so it is not a suitable mechanism for providing a nice reading experience for users.

Reader Mode

Firefox now offers Reader View which attempts to display a page in a format optimized for reading. It is a nice feature and I use if fairly regularly, but it has a number of downsides.

  1. It requires the user to enable it for each site. I can’t ask for it to be enabled automatically on load.
  2. It is heuristic based, I have no way to ensure that my site works properly (now or into the future).
  3. It provides no mechanism for custom content. So I can’t embed highlighted code, or interactive widgets.

Reader mode is a step forward, and will always be useful to provide dramatic improvements to some awful sites, but it doesn’t seem capable to provide a top-quality experience in many cases.

My Proposal

I think the solution is to empower the default stylesheet. Much like Reader Mode can take full control of the content to display it in a readable way, we need to let the browser’s default stylesheet do the same. However in order to do that we need to overcome the shortcomings of the first two approaches. I think the key is making this “enhanced stylesheet” opt-in instead of opt-out so that styles can be changed without breaking existing sites. Furthermore it will be possible to opt-out specific sections of the page. This would allow embedded interactive content inside of a readable document.

To be concrete:

  1. Sites can mark elements as “content”. These elements are styled with an opinionated default stylesheet. The site author can still tweak the style with custom CSS, but they should be careful to avoid changes that may conflict with the browser style, any breakage would be “their fault”.
  2. Sites can mark elements as “chrome”. These elements are excluded from the above styles. The default styles applied to this element and its children would either be the current browser default stylesheets or ideally a very consistent stylesheet. (For example white background, black text, no margins, padding or borders, no text decoration and similar. Semantic elements should still be selected but they would all have the same default styles.)

CSS doesn’t have good support for “elements under .content but not under .chrome” in the way that would be needed to implement this. But I managed to make a mockup (ab)using CSS variables.

<style>
    .content {
        /* Enable content rules. */
        --content-only: ;

        color: var(--content-only) blue;
    }

    .content p {
        border: var(--content-only) 1px solid black;
    }

    .chrome {
        /* Disable content rules. */
        --content-only: -invalid;

        /* Reset inherited properties. */
        color: initial;
    }
</style>

<p>The root is chrome.</p>

<article class=content>
    <p>This is content</p>
    <div class=chrome>
        <p>Back to chrome</p>

        <div class=content>
            <p>In content again</p>
        </div>
    </div>
</article>

This applies silly styles to demonstrate the point, but it is easy to imagine a beautiful set of styles for the content sections. If I had any design skills I would turn it into a simple CSS library for nice readable sites. (If you do this let me know.) But the full power wouldn’t be realized until it is part of the browser and controlable by the user.

The opt-in mechanism would need to be more unique than a content class. But the idea is simple and effective.

Summary

There is a conflict on the web between documents, which are usually best viewed with the user’s preferences and “apps” which should still respect the user’s preferences where possible but often have complex styles that are sensitive to many browser tweaks. Separating these two use cases would provide the best of both worlds; readable content and easy, consistent chrome.

Top comments (0)