jensimmons/cssremedy

Start your project with a remedy for the technical debt of CSS.

cssremedy's Issues

Look up / figure out today's best practice in setting font-size

For years, we've been doing this:

html {
  font-size: 100%;`
}

as the best practice. That starts out most users with a default font size of 16px. But leaves the typography size easily changed with zooming.

What's today's best practice? Do UA files set font-size in px? Do they already set it to 100%, making this line of code redundant?

What is best today?

Every once in a while, someone revisits this question and writes up a blog post. Where are we at on this now?

overflow-wrap: break-word

Personally, I default to use html { overflow-wrap: break-word; } (https://www.w3.org/TR/css-text/#overflow-wrap-property) specifically to allow wrapping of long text strings such as displayed URLs. I haven't observed any issues with this, but I can imagine there may be unexpected behavior with mixing certain writing-modes or some such.

See this anonymous glitch for a quick demonstration:
https://pool-highfalutin-pickle.glitch.me

Demo HTML

Copy & paste to open in a browser:

<style>
  /* Simulate a viewport size that is smaller than a long URL embedded on the page */
  viewport-size {
    display: block; 
    width: 320px;
    font-size: 16px;
    border: dotted 2px;
  }
  input:checked ~ viewport-size {
    overflow-wrap: break-word;
  }
</style>
<input id="overflow-wrap" type="checkbox">
<label for="overflow-wrap">
  Set <code>overflow-wrap: break-word</code>
</label>
<viewport-size>
  <p>URL: https://example.com/abcdefghijklmnopqrstuvwxyz123456789</p>
</viewport-size>

In a component world are resets needed at all?

One of the not-yet-realized promises of using web components is the confidence that a component will render as expected in any context. This means its styles will be insulated from, and won't leak to, surrounding components. For example, if I create a <Button> component the hope is that each consumer — websites in my company or third-party sites we integrate with — will be able import and render it.

The problem with resets is that they become external dependencies that both must exist and must exist in a certain order. If to use my <Button> component you have to also use my reset, someone's code is very likely going to get clobbered.

Wouldn't a better solution be to move element resets into their respective components? With this approach whatever was needed by <Button> would be contained in the <Button> component, likewise for tables, lists, headings. The only CSS that maybe wouldn't fit into this model is the global box-sizing reset *, ::before, ::after { box-sizing: border-box; } rule but potentially that, too, could be included by any components that needed it.

If you're using "naked" HTML clearly this approach won't work and a reset is useful. But I wonder if long-term we should aim for less reliance on global dependencies as web components become the standard.

Suppress the focus outline on elements that cannot be accessed via keyboard??

In Reboot, the base file for Bootstrap, they have this:

// Suppress the focus outline on elements that cannot be accessed via keyboard.
// This prevents an unwanted focus outline from appearing around elements that
// might still respond to pointer events.
//
// Credit: https://github.com/suitcss/base
[tabindex="-1"]:focus {
  outline: 0 !important;
}

Hmmmmm.

Comments?

Consider project organization and framing

With issues like #11 and #15 (and likely more to come), we run the risk of setting hard defaults where authors should be making contextual decisions. I think it is great to provide those reminders and potential solutions – but developers are accustomed to an all-or-nothing, fix-it-and-forget-it approach to resets. We either have to be pretty sure that we're solving the vast majority of use-cases, or we need to consider re-framing some of the solutions we provide.

I wonder if part of that solution is already represented in splitting quotes.css out from the rest. Could we organize the project into several layers, with different recommendations to use. Something like:

1. A base reset that you can generally use as-is without much risk. Add it to a project, and go.
2. Highly-specific resets (like quotes.css) that are overkill for most sites, but could be useful to some, in part or in full
3. Contextual fixes we recommend considering and modifying as needed for a project – with some documentation around the considerations. These could even be treated more as utility classes to be used more narrowly, e.g. providing a .reduced-motion class along with the * option.

I don't know if that's the exact breakdown or solution, but I think this project is different from other resets in that we're trying to rethink defaultst, not simply add a new reset to the already long list of options.

Better font-family defaults?

I know this is low-hanging fruit, but I'm procrastiworking.
So, basically this necolas/normalize.css#665. Normalize stuck with sans-serif, but others (e.g. Reboot, modern-normalize) go with system UI fonts.

There are plenty of examples of authoritative sites using a system UI stack (the words you're reading now: case-in-point). The idea is not new, obviously.

So stick with Times/TNR, go with sans-serif, or this?

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif;
}

(Reboot still has html { font-family: sans-serif; } as well as the above)
Or something else?

contributions from sanitize.css

Hi there. First, love it. I think a project like this with the momentum and long-term backing of Mozilla could be the “final form” of sanitize.css. I’d gladly contribute what I’ve learned there and deprecate that module in favor of something that could be managed by a dedicated team of developers. I’m all in favor of flavors, and I love the shout out in the README. Our projects seem extremely aligned in purpose, so I think it could be a win for developers to focus my efforts here.

Also, I love that you’ve split out the quotes styling into its own file. In fact, this seems like a really intelligent way to split out opinionated work that doesn’t necessarily belong in “core”. For instance, for sanitize.css I identified system-ui as a preferred design pattern in unformatted documents over serif — I suppose this is because documents are sometimes apps. Still, it bothered me to ship this as a default to the countless sites that will only overwrite the font family with their own. So yea, moving these opinionated styles into their own files seems like the right move.

I’ll be submitting some PRs with other concepts from sanitize.css (which is licensed CC0, so there’s certainly no issues there). I’m mostly opening this issue to start a conversation about my first 2 paragraphs.

Change sub & sup?

I'm in the middle of something... and tripped down multiple rabbit holes that brought me to this:

sub { font-variant-position: sub; } 
sup { font-variant-position: sup; }

The CSS WG wrote about it here: https://wiki.csswg.org/faq

Let's consider. Meanwhile, back out of this rabbit hole for me, so I can go back down the other one....

Make sure browsers use the proper quotes (including curly quotes)

https://github.com/mozdevs/cssremedy/blob/7a41665f3168a9719a404f9693a6caa30b2b502d/remedy.css#L81

See whatwg/html#3636 (comment) for a better selector to apply quotation marks.

How do we handle "reminders"?

Some remedies (like #7, or #11) are useful in some cases, but would be dangerous as universal defaults. As a first step, we've proposed putting those in a secondary reminders.css file - a reminder for authors to consider what defaults will work best for them. Is that the right solution for a project like this one?

I like the idea of reminding authors to consider certain defaults before applying them, and providing context to learn more about the issues involved. Will it work, or will authors simply default to importing both remedy.css and reminders.css globally? If we want to put up further roadblocks, there might be a few other options:

• all reminders are commented out by default, and need to be explicitly uncommented
• reminders live in a markdown file, and on the website, but are not available directly as a CSS include
• other ideas?

Ensure that `nav ul` styles are not bad for accessibility

After reading this article by @scottaohara https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html I want to open a discussion about this particular rule (list-style: none) https://github.com/mozdevs/cssremedy/blob/8108c97ce590aed9e315fce4b72824f3b09faffc/remedy.css#L68

There are evidences that it is problematic using VoiceOver with Safari (macOS and iOS), it removes the list semantics.

As @scottaohara points in the article, using one of these rules maybe is better to avoid removing list semantics:

list-style: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'/%3E");

// or

list-style: url(#!);

It's a bit hacky, maybe it's worth it.

PS: thanks for this project 👌

Cater for "hidden" attribute

Setting display: block; on elements will overwrite the hidden attribute's functionality. Currently cssremedy is putting display block on a variety of elements.

I guess the preferred way is to have img:not([hidden]) { display: block; } etc.
Or perhaps specify [hidden] { display: none } to save on filesize?

What's best for `prefers-reduced-motion`?

I wrote

/* Stop any animation if the user has set their device to "prefers reduced motion". */
@​media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
    animation-duration: 0.1s !important;
    transition-duration: 0.1s !important;
  }
}

Or I should say, I snagged that code from discussions on Twitter. Which I'd linked to, but then erased the link. Hm, I should find it again.

@meyerweb raised a good point — why 0.1s and not 0?

Also, do browsers not do this already? Is there no mandate in the CSS spec for user agents to enforce this? Why not? Or if there is (and browsers just haven't implemented it yet), then what is it? What was the discussion about this?

Likely there's some back story with wisdom we can draw from.

Consistent and reliable form styles

Form consistency and styling is one of the biggest hurdles I face when working. The box model, sizing, and font settings don’t inherit reliably. Attempts at normalizing forms often require vendor specific CSS.

I’d personally like to see the w3c take this on to create some standards in how form components should be styled, but it seems relevant to this project to remedy some of these issues. I’m curious how others work through these issues and what foundational styles you all find helpful.

Relation to normalize/sanitize.css

Hi, can you please elaborate on what is the difference from other solutions like e.g. well-known normalize or sanitize.css. I mean why did you decide to make a new one? It would help me to know why should I use it when I sanitize.css already. Thank you.

Attribution Question

This is more of a question than an issue:

I just set this up as a ruby gem.

I'd like to give proper attribution on https://github.com/blakeprudhomme/cssremedy-rails.

Can someone please advise if there is a more specific credit I should put other than "Mozilla Developer Outreach."

What does `:root:lang(x), :not(:lang(x)) > :lang(x)` catch that `lang(x)` doesn’t?

I see that the source from the HTML spec is autogenerated, but the source code what does that generation doesn’t indicate why these particular selectors. The Git history for the line that generates the selectors ends with the initial move to GitHub, so I couldn’t find any historical context.

The :not(:lang(x)) > :lang(x) selectors seem like they could be expensive, so I’m interested in why they exist. Is it a source order thing? What does…

:root:lang(en),
:not(:lang(en)) > :lang(en)

…select that :lang(en) doesn’t?

Better indentation for blockquote, dl, ul, ol, figure, menu, dir, etc

I can’t find if a spec recommends this, but modern browsers add margin: 1em 40px to <figure>, such as this declaration from Firefox’s html.css UA stylesheet (resource://gre-resources/html.css):

blockquote, figure {
  display: block;
  margin-block-start: 1em;
  margin-block-end: 1em;
  margin-inline-start: 40px;
  margin-inline-end: 40px;
}

The 1em is reasonable and matches <p>, but giving up 80 pixels out of 320 on most phones seems like a lot — 25%!

The unit mismatch also bothers me, but I’m not sure that’s an actual problem.

Evaluate effect of removing list semantics in nav

There has been recent discussion around the impact list-style: none; has on screen readers, particularly VoiceOver. Sara Soueidan Tweeted that this removes <ul>/<li> semantics in VoiceOver, and Scott O'Hara recently wrote about this in greater length.

Is this remedy intentionally removing these semantics within a <nav>?

https://github.com/mozdevs/cssremedy/blob/20be8a0abcd3cdfba32b3cbe2c2c7d7d5acb5036/remedy.css#L67

height 100% or 100vh on body & html?

Do we want to include something like:

html, body {
  height: 100%;
}

or

html, body {
  min-height: 100vh;
}

???

to keep the page from being super short in the browser window.

Set line-heights on headlines

One of my pet peeves is when developers forget to reset the line-height on headlines, and the UA default is used. Usually this results in there being more space between wrapping lines in an h1, h2, etc than there is space between that headline and the other content before or after it. (line-height is bigger than top or bottom margin).

In the stylesheet, for each headline, I wrote something like:

h2 {
  font-size: 1.5rem;
  line-height: 1;
}

I tossed line-height: 1 in there as a placeholder. We should take some time to decide what value it should be. 1 is likely too tight.

CSS contains git merge output

Heya! I noticed the CSS file contains git merge resolution output. https://github.com/mozdevs/cssremedy/blob/master/remedy.css#L64-L67

It was added in this commit.

Create an `alt` stylesheet

Discussion on Issue #48 reminded me of something @mirisuzanne and I were discussing a few weeks ago. We settled on having two different [kinds of] stylesheets in Remedy — clearly marking the code we think will help every (new) website ever. And code that might help your particular website, but you should read it, pick through it, and manually add just the things that will help for you.

Why?

The CSS Working Group has two constraints when creating new CSS / Browsers have two constraints when adding new CSS.

1. The change to CSS itself must not break existing websites.
2. The new defaults must work for every website ever. Every script. Every language. Every writing mode. Every weird edge case or bug.

Remedy does not have the first constraint. We aren't changing the browser. We are offering a better starting place for new sites / new codebases. If an Author wants to throw Remedy at an existing pile of CSS, then it's up to them to QA test and make sure they aren't breaking anything.

It's tempting to blow off the second constraint. Many of us who write CSS as a front-end developer live with this reality all the time. If I'm building a site that hosts user-generated content, I don't know what kinds of content people might be making.... but I do make some assumptions and support 80% of usecases. Maybe 90%. I don't worry about the extremely rare case. I don't have time. So I may not test my comment section for every language, or every weird combination of characters. It's likely my boss would rather live with a bug or two than run up the budget.

But with Remedy, there's a chance this project will get picked up by very popular themes/frameworks/starter-kits, and will be used for a large global audience. We don't want to write code that only works sometimes.

So here's a solution, so that we can provide hints and help that'll work 80% of the time... while not leaving out the 20%.

Let's create two stylesheets — the main Remedy stylesheet will only have code that always works all the time for everything. And there'll be an "Alt" stylesheet that invites people to read it, and move over any code that will work for them.

Options for sub and sup can be one such example in the Alt stylesheet. Include documentation (comments in the code) that explains why this is good, wand why it might be a problem. Empower the author to decide for themselves. Encourage people fork Remedy and make it their own, customizing it for their project. And then encourage the Bootstraps and Wordpress projects of the world to never include any of the Alt code by default. Just the main code. Alt can be passed along to the developers of each site to read through it.

`display:block` negates `vertical-align`

I believe vertical-align applies to (see Formal Definition on MDN):

inline-level and table-cell elements. It also applies to ::first-letter and ::first-line.

So I doubt it does anything in the rule below as it is associated with display:block:

/*
* 1. Block display is usually what we want
* 2. Remove strange space-below when inline
* 3. Responsive by default
*/
img, svg, video, canvas, audio, iframe, embed, object {
  display: block;
  vertical-align: middle;
  max-width: 100%;
}

display: block alone should take care of #2 ("Remove strange space-below when inline")

adjustments for <hr>

From Reboot (Bootstrap's) and Normalize:

/**
 * 1. Add the correct box sizing in Firefox.
 * 2. Show the overflow in Edge and IE.
 */

hr {
  box-sizing: content-box; /* 1 */
  height: 0; /* 1 */
  overflow: visible; /* 2 */
}

Thoughts? We should test this.

Including upcoming properties that aren't in browsers yet?

Are you also interested in properties that haven't been (broadly) implemented yet, but for which we know the initial value and legacy behavior will not be the best behavior, and lets people opt into better behavior? If yes, I suggest:

:root { line-sizing: normal; }

and

:root {
  text-spacing: trim-start allow-end trim-adjacent ideograph-alpha ideograph-numeric;
}

img without height definition ignore aspect ratio

By not defining height: auto;, images do not maintain their aspect ratio due to max-width:100%;

codepen example

Feedback to go through: A To-Do List

https://twitter.com/jensimmons/status/1082396940237750272

hello, <canvas> element

Somewhere in all the discussion of img, someone mentioned that he found the same problems with canvas.

Perhaps we should add:

canvas {
  vertical-align: bottom;  
  display: block; 
  max-width: 100%; 
}

More investigation needed.

Consider removing top margins from headlines and paragraphs

One of the items listed on the CSSWG List of Mistakes in the Design of CSS, is this:

The top and bottom margins of a box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil.

I'm not sure that there's consensus within the CSSWG about this (and it doesn't matter, since we don't have a timemachine), but clearly at least some folks wish margin collapsing wasn't created.

In that vein, the CSS Reboot in Bootstrap removes all top margins from headlines and paragraphs.
https://getbootstrap.com/docs/4.0/content/reboot/#headings-and-paragraphs

All heading elements—e.g., <h1>—and <p> are reset to have their margin-top removed. Headings have margin-bottom: .5rem added and paragraphs margin-bottom: 1rem for easy spacing.

This is one way to effectively remove much of the annoyance or unexpectedness of margin collapsing.

I don't know that this is a good idea, but I thought I'd open an issue were we can discuss.

New default value for the `background-repeat` property

I think the historical default value of the background-repeat property is a perfect example of what the CSSWG would set differently if UA stylesheets were being written today. While repeating background patterns may have been common in the early web, they are now the exception, not the norm. As such I think we should consider changing the default behavior for background repetition.

*, ::before, ::after {
  background-repeat: no-repeat;
  box-sizing: border-box;
}

Include `text-size-adjust: 100%;` or not

I see that text-size-adjust: 100%; is included with the description Fix for iOS Safari. This make it sound that iOS has a text sizing bug, but I think it's a feature to resize text on orientation change.

@tbrown writes in Flexible Typesetting:

A value of 100% prevents type from being resized automatically in iOS when a device’s orientation changes. That might be a problem if a reader expects type to get larger in landscape mode for easier reading.
Personally, I avoid text-size-adjust entirely. It can cause serious accessibility problems, it is sometimes overridden by the aforementioned viewport settings, and browser implementation is inconsistent right now.

If this is going to be included, I think a better description would be used: Prevent type from being resized in iOS when a device’s orientation changes.

vertical-align and alt text

Originally from #14:

I ran into an issue recently with img { vertical-align: middle } at work.

If an image breaks and falls back to its alt text, a vertical-align other than baseline produces different behavior across browsers. Here’s a CodePen to demonstrate.

• Older (current?) versions of Firefox have the alt text dip below the baseline
• As of Firefox Nightly 71.0a1, though, the changing of vertical-align appears to be ignored and the text flows on the same baseline, which seems ideal to me.
• Chrome has the same problem as older Firefox, along with a broken image icon

Is it worth trying to fix this problem with selectors specifically for alt text? (Like img:is(:-moz-broken, :-moz-loading, :-moz-user-disabled))

How far back to do we go in supporting old IE by fixing its bugs?

Many of projects similar to this have been removing their code that fixes bugs in really old versions of Internet Explorer.

This code for instance:

article, aside, figcaption, figure, footer, header, hgroup, main, nav, section {
  display: block;
}

Do we bother?

How far back to we want to "support"?

Consider not squashing the remapping of H1 onto h2, h3, h4, h5, h6 styling when nested inside sectioning elements.

All three browser engines map the formatting of an H1 to smaller headlines (h2, h3, h4, h5, h6) according to how many levels deep it is inside a sectioning element. Therefore, an h1 that's nested inside three levels of any sectioning element will be formatted like an h3.

Normalize squashes this with the following code:

/**
 * Correct the font size and margin on `h1` elements within `section` and
 * `article` contexts in Chrome, Firefox, and Safari.
 */

h1 {
  font-size: 2em;
  margin: 0.67em 0;
}

I'm going to do the same thing. I don't expect that web developers have any clue that browsers are trying to do this. I also am guessing browsers do this because the HTML outlining algorithm was supposed to encourage Authors to use H1 all over the place, knowing it would be understood as an h2, h3, h4, etc based on how many levels deep it sat in the DOM. But this didn't work out. Outlining was never implemented. So it feels like removing this styling is a way to reflect reality. The ideal was never completed.

New default `line-height` for paragraphs? Everything?

https://github.com/mozdevs/cssremedy/blob/7a41665f3168a9719a404f9693a6caa30b2b502d/remedy.css#L56

line-height: normal is a bit tight, so I understand wanting to set it to something larger (like 1.5) for readability. At the same time, line-height: normal derives its size from information in the font file, but a number doesn't do that. Being dependent on the font sounds like a feature worth keeping to me. That makes me wonder if we should get a way to do something like font-size: calc(normal * 1.2);…

Twitter/social media accounts

I grabbed the cssremedy Twitter handle, since many projects seem to have Twitter accounts to post updates, etc.

Even if this project doesn't want a Twitter presence, it might be worth protecting the name to avoid somebody else claiming to represent it.

I'm eager to turn over control of the account to somebody more appropriate ASAP, just let me know who wants to own the account :)

Text Underline position for CJK lang

This is supposed to be implemented in UA styles:
https://www.w3.org/TR/css-text-decor-3/#default-stylesheet

and it's not. So we can.

`article, etc. {display:block;}` is not enough for oldIE

Since styling HTML5 elements with display:block is not enough for oldIE to "fix" these elements, I suggest to add a comment to the rule so users understand the limitations of that rule. For example (with the addition of details):

/* @docs
label: HTML5 Elements

note: |
  Default block display on HTML5 elements
  For oldIE to apply this styling one needs to add some JS as well (i.e. `document.createElement("main")`)

links:
  - https://www.sitepoint.com/html5-older-browsers-and-the-shiv/

category: legacy browsers
*/
article, aside, details, figcaption, figure, footer, header, hgroup, main, nav, section {
  display: block;
}

Document level flag for modern defaults

Could there be a document level setting to change the default styles to a more modern set?
Similar to setting the HTML5 doctype? <!DOCTYPE html>

A simple flag maybe? <!DOCTYPE html modern> as a terrible example.
Then maybe we could have nice things.

Tables should look good, and like tables, by default

From: https://wiki.csswg.org/ideas/mistakes

For example, who ever wanted non-collapsed borders (or no borders) by default? Not sure if borders count as layout though...

Padding? Tables without padding are not readable.

Which technique for setting `box-sizing: border-box`?

We could

* { box-sizing: border-box; }

or we could

html {
	box-sizing: border-box;
}
*, *:before, *:after {
	box-sizing: inherit; /* Switching to border-box for box-sizing. */
}

which is what several people believe is best. See:
https://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice/
https://www.paulirish.com/2012/box-sizing-border-box-ftw/

Those articles reflect an agreement that by setting it to inherit on most elements, you can drop in a component that has box-sizing: content-box and everything inside that component will also be content-box.

@fantasai countered:

I don't think you want box-sizing: inherit.
Just set it to border-box on everything.
Otherwise if you decide to change it for one element, it'll inherit into the subtree and be weird.

Personally I prefer the one line version. Always have. But...

Audio tag without controls should not be `display:block`

I think it's generally good to include audio in the list of Embedded Elements that we display as block, with responsive sizing and vertical alignment. But browsers hide audio:not([controls]) by default, and I think it's a mistake for us to override that setting.

I'm not sure about the right solution. If we change that selector to audio[controls] or even just [controls] we're adding more specificity than we use elsewhere.

We need CSS Layers so that we can not worry about specificity in cases like this. 😛

Remove the default styling of fieldset?

Why don't people use <fieldset> far more — instead of divs in their forms?

Perhaps it's because fieldset comes with ugly default styling.

Maybe we should remove it?

fieldset {
    margin-inline-start: 0;
    margin-inline-end: 0;
    padding-block-start: 0;
    padding-block-end: 0;
    padding-inline-start: 0;
    padding-inline-end: 0;
    border: none;
    min-inline-size: min-content;
}

Path to v1.0?

Loving CSS remedy so far as an alternative to Normalize/my own boilerplate, but I'm hesitant to use it in prod with beta warnings everywhere. Is there an agreed upon path to a 1.0 stable release in place? What large pieces still need to be done/tested/are subject to breaking changes?

Seeing as there hasn't been much activity on the repo lately, is it worth releasing the current work as a 1.0? That's what semver is for after all, and if there are breaking changes to come we can just push out a new major version.

Fix the tiny gap under replaced elements that shows by default

I was just reading Tantek's original Reset stylesheet (likely the first ever).

He wrote

/* whoever thought blue linked image borders were a good idea? */
a img,:link img,:visited img { border:none }

OMG! That's right. There were ugly blue boxes around images that have a link. Does this still happen anyplace? I don't think so. But if it does.... we should fix it. Ha.

Meanwhile, I do think images still have that little gap below them, because they are display: inline by default (mistake, imho), and the line height for whatever text size is added to the bottom of the box. I've spent many hours of my life trying to figure out where that gap is coming from. Until I finally remembered to always include this in my CSS:

img { display: block; }

Shall we add that to Remedy? Does anyone else always do this?

white-space:pre-wrap vs. overflow:auto for `pre`

The rule for pre is as follow:

/* @docs
label: Pre Wrapping
note: |
  Overflow by default is bad...
category: typography
*/
pre { white-space: pre-wrap; }

I agree that "overflow by default is bad", but I'd argue that a better "fix" would be to prevent overflowing from happening rather than going against what this element is about:

The HTML <pre> element represents preformatted text which is to be presented exactly as written in the HTML file. The text is typically rendered using a non-proportional ("monospace") font. Whitespace inside this element is displayed as written.

As far as I can tell, pres we find in the wild are styled with overflow:auto as it prevents content from overflowing while preserving the formatting of that content. The example below shows that this is true for GitHub too:

---------------- A ---------------- B ---------------- C ---------------- D ---------------- E ---------------- F ---------------- G
                 ^                  ^                  ^                  ^                  ^                  ^                  ^ 

So I'd suggest replacing white-space:pre-wrap with overflow:auto as it is more in line with how pre is styled IRL.

How do we version and package releases?

Goals:

We haven't "released" anything yet, but I just want to think ahead about what a release might look like…

• At it's core, this project is a collection of CSS files. It should be possible to use and share the Remedy without any knowledge of versioning or package managers. You can download the files raw, or copy and paste plain CSS.
• For many of us, it's useful to have some versioning information and packaging available. It can make it easier to stay up-to-date without major headaches.

Proposal

Tagged Github releases using semver would be a good first step, without any additional tooling. From there, we might want to consider:

• Add a changelog.md to track release notes?
• Add a package.json and publishing to npm?
• For anyone using via copy/download (no package manager), is it useful to have a version number in comments at the top of each file?

---

Am I getting ahead of things here? Do others feel like it would be useful to have versioning and package management available? I think we should be able to do it in a way that doesn't add any complexity to the plain-css download/copy option.

High-Contrast Mode

While styles for Windows High-Contrast Mode are currently behind -ms- prefixes, that’s worth overlooking to better serve HCM users.

Browser support/considerations

• IE and old Edge support the -ms-high-contrast media feature and the -ms-high-contrast-adjust property
• Notably, IE ignores background-image, but Edge recognized abuse of backgrounds for content led to a worse user experience, so it does something fancier.
• Firefox supports HCM, but doesn’t perfectly inherit high-contrast colors from the Windows settings (maybe just hyperlinks?). Some configuration of the user-agent styles in settings is required. It doesn’t have a media query to target HCM, but improvements can still be made with CSS.
• Edgium and its intent to ship HCM support in Chromium may lead to standardized high-contrast CSS.

Proposed global HCM styles

At work, testing HCM revealed some styles worth applying globally, presumably oversights in IE/Edge:

@media (-ms-high-contrast: active) {
  *, ::before, ::after {
    border-image: none !important; /* falls back to border-style */
    list-style-image: none !important; /* falls back to list-style-type */
  }
}

There’s also arguments for resetting properties like filter and mix-blend-mode, but those are harder to reason about. IE/old Edge don’t support them on HTML content except in corner cases like <foreignObject> — but Edgium will.

Newer HTML5 elements could use assigned HCM colors, as some permutations of Windows, IE/Edge version, and HTML5 features can lead to visibility problems:

• <mark> in Windows 8 seems to have its color still be #000, requiring color: inherit or similar

• Beyond that bug, <mark> doesn’t render usefully in HCM, as its recommended styling is mostly background-color. An indicator can be restored in IE, Edge, and Firefox with:

  mark {
    box-sizing: border-box;
    border: 1px dotted transparent;
  }

  This renders nothing normally — but when HCM forces border-color: currentColor, it shows.

• Newer form-associated elements sometimes need attention: <meter>, <input type="range">, and <progress>, off the top of my head.

Style PICTURE with 'display: contents' and SOURCE with 'display: none'

Testcase

The picture element, being treated as an inline wrapper around the actual replaced element, prevents images with aspect ratios in participating properly in the CSS layout algorithms as images with aspect ratios. Also unless one specifically wants a wrapper, having an inline box wrapped around the image isn't really helping anyone. Also having a bunch of empty inlines representing each SOURCE element seems pretty unnecessary. Let's get rid of these boxes.

picture { display: contents; }
source { display: none; }

(Yay, a use case for 'display: contents' that isn't better served by subgrid!)