Thanks for the cool tool. Is it relevant today? If not, what exactly needs to be improved / added?

In normalize-opentype.css, on line 94 input[type="numer"] should be input[type="number"]. I was going to do a pull request, but wasn't sure if it was worth figuring out SUIT CSS for a one-character change. :)

If you can find some time to get rid of all TODOs in the stylesheet, that will be so awesome 😊 Let me know if you need any help.

Thanks a lot for this cool project 👍

Sorry I did not check yet if your "lib" will trigger this problem too but I guess it does.

Original ticket at Microsoft is here: https://connect.microsoft.com/IE/feedback/details/831964/font-feature-settings-with-open-sans-webfont-in-win7-ie-10-11-no-text-problem

It only occured for "Open Sans" for me but there may be other font that trigger this which basically destroys the page completely, somehow in IE10/Win7 only.

So this may not be a problem your code should prevent but maybe a note on the front page to look out for this possible problem would make sense.

font-feature-settings breaks text selection in any capacity but normal in Chrome on OS X. The fix is to inherit text-shadow or color within ::selection

http://robsterlini.co.uk/journal/opentype-and-selection-dont-mix

While normalize-opentype.css includes the vendor prefixing, normalize-opentype.scss doesn’t and will work best with Autoprefixer and the like. I’m open to reevaluating how this is done, if you’re using Sass and have a strong opinion, please share your setup! One option would be a vendor-prefixed version in dist/ or dropping the Sass version entirely, as I also want to avoid confusion about which file to use.

I think the ideal solution would be if libsass added support for importing plain CSS files.

I'm using the Karla font with normalize-opentype.css on my blog (see the repository for full source code). Here's the problem:

It appears that numerical characters are not displaying but if I turn off -webkit-font-feature-settings: "kern" 1, "liga" 1, "pnum" 1, "tnum" 0, "onum" 1, "lnum" 0, "dlig" 0;, the numbers appear (however the type is different and worse than it was with that turned on).

Please register an actual npm-package (npm publish). normalize-opentype name is free to register.
It’s far more convenient in npm to use npm repo that github.

To be included in the next minor version:

• "clig"
• "rlig"
• "mark"
• "ccmp"
• "locl"
• "calt" (already in a branch, #10)

If no ::selection is specified and there’s nothing to inherit, it uses transparent instead of the browser default blue.

Hello,

Great work, Do you have any plans (or discussions) to get some (or all) of your changes as part of the upstream 'normalize' project ? It makes sense doesn't it ?

Thanks for the nice defaults.

I am using the normalize-opentype.scss file, importing it into my main sheet.

We are using TypeKit and the Scala Sans font.

In current versions of FF and Chrome (Mac) as well as current Chrome Canary (Mac), the font-feature-settings property are labelled as Unknown Property Name (in Chrome Canary) in Chrome Dev Tools and is just not listed at all in FireBug in FF (elements are listed - h1, h2 etc, but the rule is empty).

I cannot post a link at this time. If it is necessary, I can make a demo page.

Hi!

I found your project today and I'm reading it.It looks really cool! And useful! Congratulations. While studying it, I found this:

Whenever possible, Web authors should use the font-variant shorthand property or an associated longhand property, font-variant-ligatures, font-variant-caps, font-variant-east-asian, font-variant-alternates, font-variant-numeric or font-variant-position.

For now, the values accept by browsrs other than Firefox are:

• normal
• small-caps
• inherit

I think you can leave this issue opened until the right moment comes.

Thanks!

The Normalize.css website simply has a big download button, and the package manager install lines. This project should have those things presented that simply as well, either in the repo or elsewhere.

I would like to see a real demo of this library to see how it works on my machine without having to download the whole thing and test it on my machine.

Not that this is necessarily the biggest concern but this property actively breaks text rendering on Android 2.3 and lower. You end up with what looks like a lot of broken Unicode characters on screen or just missing text.

Some links:

• https://code.google.com/p/android/issues/detail?id=15067
• http://stackoverflow.com/search?q=%5Bandroid%5D+optimizelegibility
• https://twitter.com/jasonsantamaria/status/453589484765212672

This is more of an FYI for your reference rather than a bug because I believe the issue is with Chrome itself (OS X only - Windows and Linux seem fine, as are FireFox, Safari and IE).

I've noticed if you have a very long page with a lot of text nodes there is a definite lag before users are able to interact with the page, i.e. before they're able to scroll, or click. You can see the page and the contents, and it's styled, but you can't do anything.

This site uses normalize-opentype and all but one of the pages are fine - we had to remove it from this page due to the performance issue mentioned above. I don't have a working example of the problem unfortunately (as I said before, I removed normalize-opentype from the page we were having problems with).

Let me know if you've come across this before and if you have any thoughts on it. Maybe if I have some spare time I'll set up a test page to see if I can replicate the problem. Of course it's very likely that new versions of Chrome on OS X will fix it...

I realised it would be possible to use different numeral sets for phone numbers (and possibly other things) in certain context. For example, in a paragraph you might want a phone number with old-style numerals:

But in most other situations you’d probably prefer tabular numerals:

I’m undecided if this within the scope of this reset. Probably my biggest deterrent is that it would use a less-than-popular selector:

a[href^="tel:"] {
  font-feature-settings: "tnum" 1, "pnum" 1, "kern" 1; /* Etc. */
}

This particular feature might be better saved for a “Going beyond Normalize-OpenType.css” set of examples, which could include the features you need to have an opinion on to use, like stylistic sets. I’m pretty open to opinions on it.

In the code there is:

/**
 * 1. Resets tables to the same settings as the body.
 * 2. Turns on tabular, lining numerals and slashed zero
 */

table {
  @extend body; /* 1.*/
}

However, this can have unfortunate results depending on the styles you have applied to body. For example, the site I'm currently working on has a dark background colour applied to body, which is subsequently being applied to all tables.

It took me ages to figure out why my tables were 'inheriting' the dark background colour - it was only by disabling some of my imports that I was able to narrow it down to normalize-opentype, and then to this specific line of code.

I can, of course, get round this by overriding the background colour on tables, but I wondered what your thoughts are on this? Isn't this @extend a bit 'far reaching'?

Why do you address both the html and the body element for the root styles? Shouldn’t it be sufficient specifying just one of them?

Chrome now does the correcting thing for tracked out text with ligatures turned on, which is great, but that’s how I was making ligatures obvious in the test suite. This will have to be changed.

Example test case

Need to test this more, but apparently this works in some places:

body {
  font-feature-settings: "kern" 1, "smcp" 1;
}

p {
  font-feature-settings: "smcp"; /* This acts like you wrote `"kern" 0;` which is annoying */
  font-feature-settings: "smcp" 1, "smcp" 1; /* What I’m doing now */
  font-feature-settings: "kern" inherit, "smcp" inherit; /* Verbose, but easier to maintain. */
}

After #2 has been fixed more than 2.5 years ago and Android 2.3 shouldn't be of any concern any more, I wonder if text-rendering: optimizeLegibility shouldn't be the included for Gecko/Blink/Webkit browsers and the font-feature properties for ~5% market share of Microsoft browsers?

I also tried dropping it into twitter.com via dev tools, and it broke the profile page in Chrome. We use inline blocks for the layout, and font-size:0 to collapse whitespace between elements. Looks like the font-feature-settings prevents that from happening.

necolas/normalize.css#343 (comment)

the UI suggestion for {calt} in the OpenType Layout tag registry is that it be implemented by default.

—Kent Lew, [source](http://typedrawers.com/discussion/651/normalizing-opentype-feature-defaults-in-css#latest)

I didn’t make any assumptions about this yet, so this will be more of an addition. I was going to only try and turn on calt for scripts somehow, but apparently this is the right behavior anyway.