BUG: em() calculations are not based off of inherited font-sizes as expected

[ravenroc]

The calculation for the em() function is based off of the size configuration option, rather than the inherited or set font-size value of the element. The em() function loses all purpose if it cannot account for the current font-size value.

Code

Within the config, the size option is set to the default 16. The following CSS is used:

.foo {
  font-size: em(12);
  padding: em(16) em(16) em(16) em(54);
}

.foo p {
  font-size: em(9);
}

Expected Output

.foo {
  font-size: 0.75em;
  padding: 1.25em 1.25em 1.25em 4.5em;
}

.foo p {
  font-size: 0.75em;
}

Actual Output

.foo {
  font-size: 0.75em;
  padding: 1em 1em 1em 3.375em;
}

.foo p {
  font-size: 0.5625em;
}

[TrySound]

It's not a bug. Value is always based on constant in configuration. font-size in rule can be overrided and you can't know this.

[ravenroc]

If it is not a bug, should I rewrite this as a feature request? The strength of using em units is that they are sized relative to the set/inherited font-size values. That's the core concept. Right now, as a workaround, I would be forced to use solely the rem() function.

font-size in rule can be overrided and you can't know this.

Can you explain this a bit more? I'm not sure how postcss cannot detect a new font-size declaration in the CSS (which is how I'm interpreting the gist of this sentence).

[TrySound]

Feature request won't be resolved because you don't know structure of your element. There's not relation between selectors in css.

[ravenroc]

There's not relation between selectors in css.

Yes, but couldn't you walk through each selector that has a font-size rule attributed to it, create a mapping, and use the mapping to make em calculations?

I've never developed a postcss plugin before, so excuse my ignorance as I try to understand how this is not feasible.

[TrySound]

No, you can't now that h1 tag name and .heading class name is the same element.